CVE-2024-56693

What it actually does

Use-after-free in the brd RAM disk driver when brd_alloc succeeds for some devices but later allocations or __register_blkdev fail, leaving disk fops pointers dangling for delayed __fput or concurrent opens that invoke release operations on freed structures.

Why it matters to the business

Kernel crashes, potential local privilege escalation, or system instability on Linux hosts that load the brd module, increasing downtime and remediation costs especially for systems relying on RAM disks during boot or testing.

How an attack unfolds

An attacker with local access forces brd module load under memory pressure or fault injection so that partial disk creation succeeds, then triggers delayed fput or device close after the module error path has freed fops, dereferencing stale pointers; similar patterns appear in broader 2024 kernel exploitation campaigns by espionage and financially motivated actors.

How to fix it

Upgrade the Linux kernel to a version containing commit 41219c147df8bbd6591f59af5d695fb6c9a1cbff or later stable releases that defer disk creation until after __register_blkdev succeeds and reintroduce brd_devices_mutex for serialization.

How to confirm the fix worked

Verify kernel source contains the referenced commit or boot a patched kernel and confirm brd module loads cleanly under memory-pressure fault injection without oops in blkdev_put_whole or bdev_release paths.

Typical attack path

1. Trigger modprobe or automatic load of brd module
2. Inject allocation failure during brd_alloc after first successful add_disk
3. Allow module init error path to release module memory while open file references remain
4. Cause delayed __fput or concurrent close on /dev/ramX to invoke freed fops->release
5. Trigger page fault or controlled memory access for UAF exploitation

How to detect it

Review kernel logs for oops involving __asan_load8, blkdev_put_whole, bdev_release, or brd_alloc failure paths; correlate with modprobe activity and any brd device opens around the time of module load errors.

• BUG: unable to handle page fault for address: fffffbfff809d073
• __asan_load8+0x4c/0xa0
• blkdev_put_whole+0x41/0x70
• brd_alloc
• brd_init

What your security team should do

• Apply the fixed kernel commit immediately on all systems that may load brd
• Disable automatic loading of brd via modprobe blacklist until patched
• Monitor kernel update channels for stable backports
• Audit workloads that explicitly use /dev/ram devices for migration to loop or tmpfs alternatives