CVE-2024-50119

What it actually does

Incorrect cleanup of cifs_io_request_pool using mempool_destroy instead of mempool_exit triggers free_large_kmalloc warning and potential memory management inconsistency during module initialization or unload.

Why it matters to the business

Systems relying on CIFS/SMB file sharing may experience kernel warnings, reduced stability during module load/unload, or unexpected behavior in high-availability or containerized Linux environments; low exploit likelihood limits immediate risk but increases operational noise.

How an attack unfolds

An attacker with local access or ability to trigger cifs module reload could induce the warning path through repeated module operations, though the flaw primarily manifests as a reliability issue rather than direct code execution; listed threat actors have targeted similar Linux kernel resource mishandling in broader campaigns.

How to fix it

Update to kernel versions containing the fix for cifs_io_request_pool handling; apply the corrected mempool_exit usage during module teardown.

How to confirm the fix worked

Confirm updated kernel source or package includes the mempool_exit change in init_cifs; test module load/unload without triggering the slub.c warning.

Typical attack path

1. Gain local access or ability to load/unload cifs module
2. Trigger cifs initialization or mempool destruction path
3. Observe or exploit resulting kernel warning and memory state

How to detect it

Search kernel logs for free_large_kmalloc warnings during cifs init; review module load traces for mempool_destroy calls on cifs_io_request_pool.

What your security team should do

• Prioritize kernel updates on systems with heavy CIFS usage
• Monitor for related kernel warnings in production logs
• Review downstream package dependencies for timely adoption