CVE-2024-26900

What it actually does

A failure of kobject_add() inside bind_rdev_to_array() leaves the rdev->serial allocation (performed via kvmalloc_node in rdev_init_serial) unreleased, producing a kernel memory leak.

Why it matters to the business

On systems using Linux software RAID, repeated triggering of the failure path can slowly exhaust kernel memory, leading to performance degradation or denial of service; the issue affects a widely used kernel component with high ecosystem prevalence.

How an attack unfolds

An attacker with local access repeatedly triggers md_add_new_disk or equivalent ioctls under conditions that cause kobject_add to fail inside bind_rdev_to_array, accumulating unreferenced serial allocations until memory pressure impacts the system.

How to fix it

Update the Linux kernel to a version containing commit fb5b347efd1bda989846ffc74679d181222fb123, which ensures rdev->serial is freed when kobject_add fails in bind_rdev_to_array.

How to confirm the fix worked

Confirm the fix commit is present in the running kernel source tree; run kmemleak scans after exercising md disk-addition paths and verify no unreferenced objects from rdev_init_serial remain.

Typical attack path

1. Obtain local user access on a Linux system using md RAID
2. Invoke md ioctl paths that reach bind_rdev_to_array with kobject_add failure conditions
3. Repeat the operation to accumulate unreleased rdev->serial allocations
4. Observe gradual kernel memory growth and eventual resource exhaustion

How to detect it

Search kernel logs and kmemleak reports for backtraces containing rdev_init_serial, mddev_create_serial_pool, or bind_rdev_to_array together with unreferenced large allocations; correlate with mdadm process activity during disk addition.

• rdev_init_serial+0x67/0x170
• mddev_create_serial_pool+0x62/0x220
• bind_rdev_to_array+0x2af/0x630
• unreferenced object.*rdev
• md_add_new_disk

What your security team should do

• Apply the referenced kernel commit or a stable update containing it as soon as possible
• Restrict unprivileged access to md-related ioctls where feasible
• Enable and periodically review kmemleak on systems running affected kernels