CVE-2024-36934

What it actually does

The vulnerability occurs because a kernel buffer allocated via memdup_user receives nbytes of data from userspace without ensuring a trailing NUL byte; subsequent sscanf on the buffer can therefore perform an out-of-bounds read past the allocated region.

Why it matters to the business

Systems running affected Linux kernels that expose the bna driver path may experience kernel memory disclosure or crashes, leading to denial of service, potential information leakage, and unplanned downtime for network-dependent workloads.

How an attack unfolds

An attacker supplies a userspace buffer lacking a terminating NUL byte to the vulnerable bna code path; the kernel copies exactly nbytes without appending a terminator, then sscanf scans past the buffer end, enabling controlled out-of-bounds kernel reads that can be leveraged for information disclosure or crash induction.

How to fix it

Upgrade the Linux kernel to a version containing commit bd502ba81cd1d515deddad7dbc6b812b14b97147, which replaces memdup_user with memdup_user_nul to guarantee NUL termination; rebuild and reboot affected systems after applying the update.

How to confirm the fix worked

Inspect the bna source for the call to memdup_user_nul in place of memdup_user, confirm the commit hash is present in the running kernel tree, and execute regression tests that exercise the previously vulnerable buffer path with non-terminated input.

Typical attack path

1. Locate a userspace interface that invokes the vulnerable bna buffer-copy routine
2. Prepare a payload of exactly nbytes without a trailing NUL character
3. Submit the payload through the interface to trigger memdup_user followed by sscanf
4. Observe resulting OOB read behavior for disclosure or denial-of-service effects

How to detect it

Review kernel logs for oops or warning messages originating from the bna driver around sscanf usage; correlate with audit records showing unusual userspace-to-kernel buffer transfers of non-text data lacking terminators.

What your security team should do

• Prioritize patching production kernels that include the bna driver within the next maintenance window
• Verify that all downstream distributions have incorporated the referenced commit before declaring systems remediated
• Add kernel build and boot-time checks to ensure the NUL-termination fix remains present after future updates