CVE-2023-53332

What it actually does

NULL pointer dereference in irq_data_get_affinity_mask() triggered when ipi_send_mask() or ipi_send_single() receive an invalid interrupt number, because ipi_send_verify() lacks a check on the 'data' parameter before dereferencing it.

Why it matters to the business

Kernel oops or panic on affected Linux systems leads to denial of service, unplanned reboots, and potential loss of availability for workloads; the age of the issue and low but present EPSS indicate ongoing exposure risk for unpatched kernels despite no known active exploitation.

How an attack unfolds

An attacker with the ability to invoke IPI send functions (typically via local code execution or a compromised kernel module) supplies an invalid interrupt number; ipi_send_verify() passes a NULL 'data' pointer onward, causing irq_data_get_affinity_mask() to dereference it and crash the kernel. Mentioned actors such as VMSCAPE are associated with related container privilege-escalation paths but no direct exploitation of this CVE is recorded.

How to fix it

Apply the upstream fix commit 926aef60ea64cd9becf2829f7388f48dbe8bcb11 or later; for packaged distributions update to the fixed versions listed for each affected product (mediawiki 1:1.13.3-1 on Debian releases and the corresponding stable kernel trees).

How to confirm the fix worked

Confirm the presence of commit 926aef60ea64cd9becf2829f7388f48dbe8bcb11 in the running kernel source tree or verify package versions match the fixed releases; test by attempting to trigger IPI paths with invalid numbers in a controlled environment and ensure no oops occurs.

Typical attack path

1. Obtain local code execution or load a malicious kernel module on a vulnerable system
2. Invoke ipi_send_mask() or ipi_send_single() with an invalid interrupt number
3. Trigger NULL dereference inside irq_data_get_affinity_mask()
4. Cause kernel oops or panic resulting in system crash or reboot

How to detect it

Monitor kernel logs for oops or panic messages referencing irq_data_get_affinity_mask() or ipi_send_verify(); correlate with process activity that could invoke IPI send paths; no public exploit artifacts are known.

What your security team should do

• Prioritize kernel updates on all production systems within the next maintenance window given the 409-day disclosure window
• Audit any custom code or drivers that call ipi_send functions to ensure valid interrupt numbers are always supplied
• Enable kernel panic-on-oops logging and monitoring to detect attempted exploitation or similar faults
• Review container and virtualization layers for additional hardening against related privilege-escalation techniques