CVE-2024-50148

What it actually does

Improper error handling in bnep_init() ignores the return value of bnep_sock_init(), causing incorrect resource cleanup; subsequent module unload via rmmod invokes bnep_sock_cleanup() and triggers wild memory access inside proto_unregister.

Why it matters to the business

Local users or automated scripts that load and unload the bnep Bluetooth module can trigger kernel crashes or denial of service, reducing system availability and requiring reboots; the issue affects any distribution shipping the vulnerable kernel code.

How an attack unfolds

An attacker with local privileges loads the bnep module in a path that causes bnep_sock_init() to fail and clean up resources, then executes rmmod; the mismatched cleanup state leads to invalid pointer dereference during proto_unregister, surfacing as KASAN wild-memory-access.

How to fix it

Update the Linux kernel to a version containing the fix that returns bnep_sock_init() result from bnep_init(); rebuild and reboot with the patched kernel; disable the bnep module if Bluetooth PAN is not required.

How to confirm the fix worked

Confirm the source change in net/bluetooth/bnep/core.c returns the result of bnep_sock_init(); test by attempting module load/unload after simulated init failure and verify absence of KASAN reports in dmesg.

Typical attack path

1. Obtain local user or root access on a Linux system
2. Trigger loading of the bnep kernel module
3. Force an initialization failure path in bnep_sock_init()
4. Execute rmmod bnep to unload the module
5. Observe wild-memory-access during proto_unregister

How to detect it

Search kernel logs and dmesg for KASAN wild-memory-access reports referencing proto_unregister during rmmod of bnep; inspect audit logs for module unload events by unprivileged users.

• KASAN: maybe wild-memory-access in range [0xdead
• proto_unregister+0xee/0x400
• bnep_init ignore bnep_sock_init
• rmmod.*bnep
• Tainted: G W.*rmmod

What your security team should do

• Prioritize kernel package updates on all affected systems
• Restrict unprivileged users from loading/unloading kernel modules via modprobe blacklist or capabilities
• Enable KASAN or similar memory debugging in test environments to catch similar issues
• Monitor kernel logs for proto_unregister and rmmod activity involving bnep