CVE-2024-35859

What it actually does

Module reference count leak in bdev_open_by_dev error path after bdev_may_open failure, leaving an unbalanced module get without corresponding put.

Why it matters to the business

Linux systems may experience improper module reference accounting, potentially preventing clean module unload or causing long-term resource accounting drift in block device handling.

How an attack unfolds

An attacker triggers bdev_open_by_dev under conditions that cause bdev_may_open to fail after the module reference has already been acquired, leaving the leaked reference; no public exploitation known.

How to fix it

Upgrade the Linux kernel to a version containing commit 0e9327c67410b129bf85e5c3a5aaea518328636f or later stable equivalent.

How to confirm the fix worked

Confirm the fix commit is present in the running kernel source tree or verify bdev_open_by_dev error paths now release the module reference on bdev_may_open failure.

Typical attack path

1. Obtain ability to invoke block device open operations
2. Force error condition in bdev_may_open after module reference acquisition
3. Observe or abuse resulting module reference imbalance

How to detect it

Inspect kernel logs for module reference warnings or block device open error paths; examine source for unbalanced module_get/module_put around bdev_may_open calls.

What your security team should do

• Apply the referenced kernel commit or newer stable release to all affected systems
• Prioritize updates on systems performing frequent block device open/close operations
• Review kernel module reference count warnings in logs after patching