CVE-2022-48832

What it actually does

Dereferencing user-controlled syscall arguments for openat2 open_how::flags inside audit_match_perm() without first validating the pointer, resulting in potential kernel oops or page fault.

Why it matters to the business

Kernel instability or crashes on Linux systems that enable auditing of file-open operations, potentially disrupting services and requiring reboots until the kernel is updated.

How an attack unfolds

An attacker issues an openat2 syscall with a crafted or invalid open_how structure; the audit subsystem then attempts to read the flags field directly from user memory, triggering an invalid memory access that can be leveraged for denial of service.

How to fix it

Upgrade the Linux kernel to a version containing commit 310c9ddfdf1f8d3c9834f02175eae79c8b254b6c or later; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel contains commit 310c9ddfdf1f8d3c9834f02175eae79c8b254b6c; test audit rules that monitor openat2 calls and verify no faults occur under load.

Typical attack path

1. Trigger openat2 syscall with malicious or unmapped open_how argument
2. Audit context records the call and later calls audit_match_perm()
3. audit_match_perm() dereferences the raw user pointer instead of the safely copied struct
4. Kernel page fault or oops occurs, leading to system instability

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for oops or page-fault entries mentioning audit_match_perm or openat2; correlate with auditd records of openat2 syscalls around the same timestamps.

What your security team should do

• Apply the fixed kernel version immediately on all production systems
• Prioritize reboot windows for high-availability audit-enabled hosts
• Monitor kernel logs for oops related to audit and openat2 until patched