Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: John Johansen <john.johansen@canonical.com>,
	Jinjie Ruan <ruanjinjie@huawei.com>,
	cve@kernel.org, apparmor@lists.ubuntu.com,
	linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com
Subject: Re: CVE-2024-56741: apparmor: test: Fix memory leak for aa_unpack_strdup()
Date: Mon, 3 Mar 2025 09:14:11 +0100	[thread overview]
Message-ID: <2025030339-playset-august-055b@gregkh> (raw)
In-Reply-To: <7286c87d1ad7b705d123f23ad213ec40a9f23351.camel@decadent.org.uk>

On Sun, Mar 02, 2025 at 06:36:35PM +0100, Ben Hutchings wrote:
> Hi all,
> 
> CVE-2024-56741 is supposed to be fixed by commit 7290f5923191 "apparmor:
> test: Fix memory leak for aa_unpack_strdup()" but I think this
> assignment should be rejected.
> 
> While a user-triggered memory leak may be exploitable for denial-of-
> service, the code that was fixed here is a part of KUnit tests.
> KUnit tests usually run a single time at boot, not under user control,
> and can then later be invoked through debugfs by the root user.
> 
> Firstly, it is intended that the root user can deny service through the
> reboot system call, so I don't think additional ways to do this are
> security flaws.
> 
> Secondly, the KUnit documentation at <https://docs.kernel.org/dev-
> tools/kunit/run_manual.html> says:
> 
>     Note:
> 
>     KUnit is not designed for use in a production system. It is possible
>     that tests may reduce the stability or security of the system.
> 
> so I don't think security issues in KUnit tests generally deserve CVE
> IDs.  (That said, the help text for CONFIG_KUNIT does not have such a
> warning.)

Now rejected.

While I know that kunit says "do not use in production", that flies in
the face of a few hundred million devices out there that does have kunit
running on them, so we need to still track these, sorry.

Also, for systems where "root is locked down" preventing it from running
`reboot`, it can many times do other things, like poke around in
debugfs, so we need to track them as well.  In other words, we don't
know your use case :(

thanks,

greg k-h

      reply	other threads:[~2025-03-03  8:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-02 17:36 CVE-2024-56741: apparmor: test: Fix memory leak for aa_unpack_strdup() Ben Hutchings
2025-03-03  8:14 ` Greg KH [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2025030339-playset-august-055b@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=apparmor@lists.ubuntu.com \
    --cc=ben@decadent.org.uk \
    --cc=cve@kernel.org \
    --cc=john.johansen@canonical.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=ruanjinjie@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox