CVE-2026-98074: bonding: do not clear curr_active_slave prematurely when releasing all slaves

Published Sep 25, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

bonding: do not clear curractiveslave prematurely when releasing all slaves

When releasing all slaves during bond destruction (all == true), bondreleaseone() unconditionally clears bond->curractiveslave to NULL in every iteration.

If a backup slave is released before the active slave, bondalbdeinitslave() triggers rlbteachdisabledmaconprimary(), which increments the active slave dev promiscuity counter and sets bondinfo->primaryispromisc = 1.

Because bond->curractiveslave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bondchangeactiveslave(bond, NULL) is skipped. Consequently, bondalbhandleactivechange() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown.

When oldcurrent == slave, bondchangeactiveslave(bond, NULL) already sets bond->curractiveslave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave).

Affected Software

1 affected component
Linux Linux kernel

Event History

Sep 25, 2026
CVE Published
via MITRE·10:24 AM
Data Sourced
via MITRE·10:24 AM
Description

Frequently Asked Questions

1

Under what conditions can the physical interface remain in promiscuous mode?

The condition occurs during bond destruction when all slaves are released and a backup slave is released before the active slave. The active slave's promiscuity counter may be incremented during ALB cleanup but not decremented when the active slave is subsequently released.

2

Which bonding configuration path is implicated?

The described behavior involves the bonding ALB cleanup path, specifically bond_alb_deinit_slave() and active-slave change handling. The issue requires teardown of a bond with both an active and backup slave in the relevant release order.

3

What is the observable impact after teardown?

The physical device used as the active slave can remain permanently in promiscuous mode after the bond is destroyed, due to a leaked promiscuity counter.

4

How does the fix prevent the leak?

The fix avoids clearing curr_active_slave while releasing every slave during all-slave teardown. This allows release of the actual active slave to invoke the active-slave change handling that decrements the promiscuity counter.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203