CVE-2024-56741: apparmor: test: Fix memory leak for aa_unpack_strdup()

CVE-2024-56741: apparmor: test: Fix memory leak for aa_unpack_strdup()

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

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.)

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: CVE-2024-56741: apparmor: test: Fix memory leak for aa_unpack_strdup()

[Greg KH]

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