In the Linux kernel, the following vulnerability has been resolved:
bonding: fix oops during rmmod
"rmmod bonding" causes an oops ever since commit cc317ea3d927 ("bonding:
remove redundant NULL check in debugfs function"). Here are the relevant
functions being called:
bonding_exit()
bond_destroy_debugfs()
debugfs_remove_recursive(bonding_debug_root);
bonding_debug_root = NULL; <--------- SET TO NULL HERE
bond_netlink_fini()
rtnl_link_unregister()
__rtnl_link_unregister()
unregister_netdevice_many_notify()
bond_uninit()
bond_debug_unregister()
(commit removed check for bonding_debug_root == NULL)
debugfs_remove()
simple_recursive_removal()
down_write() -> OOPS
However, reverting the bad commit does not solve the problem completely
because the original code contains a race that could cause the same
oops, although it was much less likely to be triggered unintentionally:
CPU1
rmmod bonding
bonding_exit()
bond_destroy_debugfs()
debugfs_remove_recursive(bonding_debug_root);
CPU2
echo -bond0 > /sys/class/net/bonding_masters
bond_uninit()
bond_debug_unregister()
if (!bonding_debug_root)
CPU1
bonding_debug_root = NULL;
So do NOT revert the bad commit (since the removed checks were racy
anyway), and instead change the order of actions taken during module
removal. The same oops can also happen if there is an error during
module init, so apply the same fix there.
Security readout for executives and security teams
Plain-English summary
CVE-2024-39296 is a Linux kernel bonding driver bug that can cause a kernel oops during bonding module removal or related bonding cleanup. The available evidence points to an availability and stability risk, not remote compromise. No active exploitation is reported in the supplied sources.
Executive priority
Patch through normal kernel update channels, with higher priority for network-critical hosts using bonding. This does not currently justify emergency response based on the supplied evidence, but it can affect availability during maintenance or network reconfiguration.
Technical view
The issue is in Linux bonding debugfs teardown ordering. During module exit or failed initialization, debugfs cleanup can race with bond device uninitialization, leading to removal calls after the shared debugfs root is cleared. Stable kernel commits change the teardown order rather than reverting the earlier NULL-check removal.
Likely exposure
Exposure is most likely on Linux systems running affected 6.6-era or later kernels with the bonding driver available or in use. Systems not using bonding are less likely to encounter the trigger, but still depend on kernel packaging and module availability.
Exploitation context
The supplied sources describe crashes during module removal, bond cleanup, or initialization error handling. They do not show remote exploitation, privilege escalation, public exploit availability, or CISA KEV listing. Treat this primarily as a local operational denial-of-service concern unless vendor advisories add stronger evidence.
Researcher notes
The root cause is teardown sequencing around bonding_debug_root and debugfs removal. The CVE text explicitly says reverting the earlier commit is incomplete because the old NULL check was racy. Analysis should focus on fixed kernel backports and distro-specific package mapping.
Mitigation direction
Update to a vendor kernel containing the referenced stable bonding fixes.
Check Linux distribution advisories for fixed package versions.
Avoid unnecessary bonding module removal on affected systems before patching.
Prioritize systems where bonding changes are part of automation or maintenance workflows.
Validation and detection
Inventory kernels and identify hosts using the Linux bonding driver.
Compare kernel packages against vendor advisories and the referenced stable commits.
Review maintenance automation for bonding module unload or bond cleanup operations.
Monitor affected hosts for kernel oops events related to bonding or debugfs cleanup.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-39296 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.