CVE-2026-53337
NoneCVSS
—
EPSS
0.1%
Published
Jul 1, 2026
CISA due date
—
Cloudanix analysis
A locally privileged user could crash affected Linux systems by sending a malformed network bonding request.
- Exploitation
- Local Privilege
- Attacker needs
- High Privilege
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
This is a local Linux kernel denial-of-service flaw in the bonding network driver ioctl path. When a privileged user with CAP_NET_ADMIN submits a bonding ioctl such as enslave or release with a non-existent slave interface name, the kernel looks up the interface, receives NULL, and then dereferences that NULL pointer in a debug logging macro before validating it. The result is a kernel oops and, depending on kernel configuration and system policy such as panic_on_oops, possible system crash or reboot.
Why it matters to the business
Successful exploitation can interrupt Linux hosts that use or load the bonding driver, causing service downtime, failed network connectivity, or node instability. The flaw requires local administrative network capability rather than remote unauthenticated access, so risk is highest on multi-tenant systems, container hosts, CI/build workers, bastion systems, or environments where users, containers, or automation can obtain CAP_NET_ADMIN. It is not listed in CISA KEV, has no known mature public exploitation, and has a low EPSS score, so remediation should be prioritized based on exposure of local privileged users and operational criticality rather than broad internet exploitation risk.
How an attack unfolds
An attacker first gains local code execution or shell access on a Linux system and obtains CAP_NET_ADMIN, either directly as a privileged user or indirectly through a privileged container, namespace configuration, or misconfigured service. They then invoke the bonding ioctl interface against a bonding device using an operation such as SIOCBONDENSLAVE or SIOCBONDRELEASE and provide a slave interface name that does not exist. The bonding driver attempts to resolve that interface name, receives a NULL result, and reaches a debug statement that dereferences the missing device pointer before the NULL check. This triggers a kernel oops and may destabilize or crash the host, producing a local denial of service.
How to fix it
Update the Linux kernel to a version that includes the bonding driver fix moving the slave_dbg() call after the NULL check in bond_do_ioctl(). If vendor fixed package versions are not yet available, apply the relevant distribution kernel security update as soon as it is released. As interim mitigations, restrict CAP_NET_ADMIN to only trusted users and services, avoid running containers with --privileged or unnecessary NET_ADMIN capability, limit access to network namespace creation where possible, and unload or avoid enabling the bonding module on systems that do not require network bonding. Review sysctl behavior for kernel oops handling, but do not rely on panic settings as a substitute for patching.
How to confirm the fix worked
Confirm the running kernel includes the vendor patch for the bonding driver NULL dereference in bond_do_ioctl(). Validate that the installed and booted kernel versions match the remediated package, not only that the package is present on disk. On Linux distributions, check vendor advisories and package changelogs for the bonding fix, then reboot into the updated kernel where required. Confirm exposure reduction by auditing processes, containers, and users granted CAP_NET_ADMIN and by verifying that untrusted workloads cannot run privileged containers or perform bonding ioctl operations. If testing in a controlled lab, attempting the malformed bonding ioctl with a non-existent slave name should return an error such as ENODEV rather than causing a kernel oops.
Typical attack path
- Gain local execution on a Linux host where the bonding kernel functionality is available.
- Acquire CAP_NET_ADMIN privileges, for example through root access, a privileged container, or overly broad Linux capabilities.
- Identify or create access to a bonding interface and the bonding ioctl control path.
- Submit a bonding ioctl operation such as enslave or release using a non-existent slave interface name.
- Trigger the NULL pointer dereference in bond_do_ioctl().
- Cause a kernel oops, crash, reboot, or network/service disruption depending on kernel settings.
How to detect it
Look for evidence of kernel oops or panic events in kernel logs, system journals, crash dumps, and centralized log collectors. Primary sources include dmesg output, journald kernel facility logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore artifacts, and EDR telemetry for local command execution involving network bonding tools or custom ioctl callers. Search for NULL pointer dereference messages with stack traces containing bond_do_ioctl, bonding, or ioctl-related frames. Also review auditd logs for processes granted or using CAP_NET_ADMIN, suspicious use of ip, ifenslave, nmcli, or custom binaries around the time of the crash, and container runtime events showing privileged containers or NET_ADMIN capability. Exploitation is likely to appear as a local crash event rather than a remote network signature; absence of logs may occur if the system immediately panicked or rebooted before logs were flushed.
- bond_do_ioctl
- BUG: kernel NULL pointer dereference
- Unable to handle kernel NULL pointer dereference
- RIP: 0010:bond_do_ioctl
- Call Trace:
- SIOCBONDENSLAVE
- SIOCBONDRELEASE
- ifenslave
- CAP_NET_ADMIN
- --cap-add=NET_ADMIN
- --privileged
- panic_on_oops
- /var/crash
- /proc/vmcore
What your security team should do
- Prioritize patching Linux systems where untrusted users, containers, automation jobs, or third-party workloads can obtain CAP_NET_ADMIN.
- Audit container runtimes and orchestration policies for privileged containers or unnecessary NET_ADMIN capability and remove it wherever possible.
- Identify systems using Linux bonding or loading the bonding module and ensure they receive the fixed kernel first if they are multi-user or high-availability hosts.
- Monitor kernel logs for NULL pointer dereferences referencing bond_do_ioctl or bonding ioctl operations.
- Ensure hosts have been rebooted into the fixed kernel after package installation.
- For high-availability services, schedule remediation through rolling maintenance to avoid avoidable outages while closing the local DoS path.
The record
In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|