CVE-2023-52443

What it actually does

Null pointer dereference in aa_alloc_profile() after aa_splitn_fqname() returns NULL tmpname for a namespace-only string like ":samba-dcerpcd" supplied from userspace during unpack_profile(), causing strlen() crash on NULL.

Why it matters to the business

Local denial of service prevents loading or replacing AppArmor profiles, potentially leaving systems without mandatory access controls or causing kernel panic during policy updates.

How an attack unfolds

An attacker with permission to invoke apparmor_parser or policy_replace supplies a packed profile whose name unpacks to only a namespace qualifier, triggering the crash path in aa_unpack when the kernel attempts to initialize the profile structure.

How to fix it

Update the Linux kernel to the commit 9286ee97aa4803d99185768735011d0d65827c9e or later stable releases that reject such malformed profiles with EPROTO during unpack_profile.

How to confirm the fix worked

Verify the running kernel contains commit 9286ee97aa4803d99185768735011d0d65827c9e, attempt to load a test profile with only a namespace qualifier and confirm EPROTO is returned instead of a crash, and review kernel logs for absence of the strlen null-deref signature.

Typical attack path

1. Obtain local access or ability to write to /sys/kernel/security/apparmor/.load or equivalent policy interface
2. Craft a profile string containing only a namespace component with no profile name
3. Invoke aa_replace_profiles or profile_replace via the parser or direct write
4. Trigger null dereference inside strlen during aa_alloc_profile
5. Cause kernel oops or panic

How to detect it

Search kernel logs and crash dumps for general protection faults or KASAN reports referencing strlen, aa_alloc_profile, unpack_profile, or apparmor_parser; examine audit logs around policy_replace or vfs_write calls to the AppArmor interface for unusual profile names containing only namespace prefixes.

• aa_alloc_profile+0xb1
• unpack_profile+0x3bc
• general protection fault.*null-ptr-deref
• apparmor_parser
• aa_splitn_fqname

What your security team should do

• Apply the fixed kernel version containing commit 9286ee97aa4803d99185768735011d0d65827c9e as soon as possible on all affected systems
• Restrict unprivileged access to AppArmor policy loading interfaces until patched
• Monitor for kernel oops involving aa_alloc_profile and apparmor_parser