CVE-2026-43103

What it actually does

This is a local denial-of-service flaw in the Linux kernel lapbether networking code. The lapbeth_data_transmit() path assumes the lower network device is Ethernet-compatible, but a device type change, such as one caused through bonding-related network reconfiguration, could violate that assumption. The fix rejects incompatible NETDEV_PRE_TYPE_CHANGE events so the lapbether driver is not left operating on an unexpected device type. Successful exploitation can trigger a kernel fault, hang, or panic, impacting system availability. The vulnerability requires local access with privileges sufficient to manipulate relevant network interfaces or bonding configuration; it is not remotely exploitable based on the published vector.

Why it matters to the business

An attacker with local access could crash or destabilize affected Linux systems, causing service interruption, failed workloads, or node unavailability. The practical risk is highest on systems where untrusted or semi-trusted users can administer network interfaces, load networking modules, manage containers with elevated network capabilities, or otherwise alter bonding and interface configuration. EPSS is very low, there is no known CISA KEV listing, no known ransomware association, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, availability impact can still be significant for critical Linux servers if local privilege boundaries are weak.

How an attack unfolds

An attacker first obtains local access to an affected Linux system and gains enough privileges or delegated capabilities to create, modify, or reconfigure network interfaces. They then arrange for lapbether to be used with an underlying device that initially satisfies the driver expectations, and subsequently trigger a network device type transition through bonding or related interface operations. Because the vulnerable kernel path does not properly block the pre-type-change event, lapbeth_data_transmit() can later operate under an invalid assumption that the underlying device remains ARPHRD_ETHER. This may cause a kernel crash, oops, panic, or networking subsystem instability, resulting in denial of service. There are no named threat actors or known active exploitation campaigns associated with this issue in the supplied intelligence.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the upstream fix for lapbether handling of NETDEV_PRE_TYPE_CHANGE. No exact fixed package versions were provided, so use the security advisory and package repositories for the relevant Linux distribution or appliance vendor to identify the corrected kernel build. After upgrading, reboot into the fixed kernel and remove or disable the vulnerable old kernel where operationally appropriate. If immediate patching is not possible, reduce exposure by restricting local administrative access, limiting CAP_NET_ADMIN and privileged container use, preventing untrusted users from loading or configuring lapbeth/lapbether-related networking, and disabling unused lapbeth/lapbether functionality or modules if they are not required. Because this is a kernel availability issue, mitigation should prioritize multi-user servers, virtualization hosts, container platforms, and systems where network configuration is delegated to non-root users or automation.

How to confirm the fix worked

Confirm the system is running a kernel build from the operating system vendor that includes the lapbether NETDEV_PRE_TYPE_CHANGE fix. Validate using package manager metadata, vendor changelogs, and the running kernel version from uname -a after reboot. Check whether lapbeth/lapbether functionality is present or loaded using lsmod, modinfo, and kernel configuration data where available. For exposure validation, review whether users, services, containers, or automation have CAP_NET_ADMIN or equivalent permissions to manipulate bonding and network device types. In a non-production test environment, verify that incompatible underlying device type changes are rejected rather than allowed to leave lapbether in an invalid state. Do not validate by attempting crash-triggering tests on production systems.

Typical attack path

1. Obtain local shell access to an affected Linux host.
2. Acquire or abuse privileges/capabilities that allow network interface manipulation, such as administrative access, CAP_NET_ADMIN, or equivalent delegated control.
3. Ensure the vulnerable lapbether/lapbeth code path is present and usable on the system.
4. Create or modify a network configuration involving lapbether and an Ethernet-like lower device.
5. Trigger a device type change through bonding or related network reconfiguration that breaks lapbether's Ethernet-device expectation.
6. Cause traffic transmission or driver activity that reaches lapbeth_data_transmit() after the incompatible type change.
7. Induce kernel instability, oops, panic, or system hang, producing a denial of service.

How to detect it

To determine whether this issue may have already been exploited, review kernel and system logs for crashes or warnings involving lapbeth, lapbether, bonding, device type changes, or lapbeth_data_transmit(). Relevant sources include dmesg output, systemd journal entries for the kernel, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore artifacts, and hypervisor or orchestration restart events. Correlate any kernel oops or panic with recent commands or audit events involving ip, ip link, modprobe, insmod, rmmod, network bonding configuration, container launches with CAP_NET_ADMIN, or privileged network namespace operations. On systems with auditd, search for execution of network administration tools and module-loading activity near the time of unexpected crashes. Since no public exploit indicators or actor-specific artifacts are known, detection should focus on behavioral evidence: unexpected local network reconfiguration followed by kernel faults mentioning lapbeth/lapbether or unexplained reboots of systems where those modules are present.

• lapbeth_data_transmit
• lapbeth_device_event
• lapbether
• lapbeth
• NETDEV_PRE_TYPE_CHANGE
• ARPHRD_ETHER
• kernel: BUG
• kernel: Oops
• kernel panic
• Kernel panic - not syncing
• /var/crash
• /var/lib/systemd/coredump
• /proc/vmcore
• modprobe lapbeth
• modprobe lapbether
• ip link add bond
• ip link set type bond
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching on Linux systems where local users, containers, orchestration tools, or automation can manipulate network interfaces or bonding configuration.
• Inventory systems with lapbeth/lapbether modules available or loaded, and determine whether the functionality is actually required.
• Restrict CAP_NET_ADMIN, privileged containers, sudo network-management commands, and other delegated network administration paths to trusted administrators only.
• Upgrade to a vendor-supported kernel containing the fix and reboot into the corrected kernel.
• Monitor for kernel oops, panic, or crash events referencing lapbeth, lapbether, bonding, NETDEV_PRE_TYPE_CHANGE, or lapbeth_data_transmit.
• Review recent administrative activity for suspicious network interface, bonding, module-loading, or container privilege changes on affected systems.
• If lapbeth/lapbether is unused, disable or blacklist the module as a compensating control until patching is complete.
• Treat unexpected reboots or kernel crashes on systems with lapbeth/lapbether enabled as potentially security-relevant even though no public exploitation is currently known.