CVE-2026-43424

What it actually does

This flaw is a NULL pointer dereference in the Linux kernel USB gadget Target Core Module function driver, specifically in Bulk-Only Transport command and data paths that use the ConfigFS-managed nexus object. If the USB gadget receives BOT commands while the target portal group nexus is not yet established or has just been removed, vulnerable code paths can dereference tpg->tpg_nexus without checking whether it is NULL. The result is a kernel oops or panic, causing a local denial of service. The issue does not provide confidentiality or integrity impact by itself, but it can crash affected systems that expose the USB gadget storage target functionality.

Why it matters to the business

An attacker or misbehaving USB host with the ability to interact with a vulnerable Linux device operating in USB gadget target mode can crash the device, causing service interruption, device reboot, loss of active sessions, and possible disruption to embedded, appliance, lab, kiosk, manufacturing, or edge systems that rely on USB gadget storage functionality. Because this is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, broad internet-scale exploitation is unlikely; however, environments where physical or local USB-host interaction is plausible should treat it as an availability risk.

How an attack unfolds

An attacker first needs access to a system configuration where the Linux device is acting as a USB gadget using the f_tcm USB target function. The attacker, or a malicious USB host under their control, times BOT mass-storage-style commands to arrive before the target nexus is fully configured through ConfigFS or immediately after it has been dropped. In vulnerable kernels, bot_submit_command() or related data-transfer paths fetch tpg->tpg_nexus and immediately access tv_nexus->tvn_se_sess without validating the pointer. When the race is hit, the kernel dereferences NULL, generating an oops or panic and taking the device or service offline.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix adding missing NULL checks for tpg->tpg_nexus in the USB gadget f_tcm BOT command and request processing paths. If vendor packages are used, apply the relevant distribution kernel security update as soon as it is available, since no exact fixed package versions were provided. If immediate patching is not possible, reduce exposure by disabling unused USB gadget functionality, removing or not loading the vulnerable f_tcm/USB target gadget configuration, restricting physical or logical access to USB host connections, avoiding dynamic nexus reconfiguration while untrusted USB hosts are connected, and using operational controls to prevent unauthorized devices from interacting with affected systems.

How to confirm the fix worked

Confirm that systems are running a kernel version or vendor kernel package containing the f_tcm nexus NULL-check fix. Validate exposure by checking whether USB gadget target functionality is enabled, whether ConfigFS gadget configurations include the f_tcm target function, and whether related modules are loaded. On Linux systems, review /sys/kernel/config/usb_gadget/ for active gadget definitions and check loaded modules with lsmod or modprobe configuration for f_tcm or USB target components. After patching, test in a controlled lab by connecting a USB host and exercising gadget connect/disconnect and target nexus create/drop workflows while sending BOT traffic; the expected result is graceful command failure rather than a kernel oops or panic.

Typical attack path

1. Identify or gain access to a Linux system configured as a USB gadget target using the f_tcm/USB Target driver.
2. Connect or control a USB host capable of sending crafted or precisely timed Bulk-Only Transport commands to the gadget device.
3. Trigger a race by sending BOT commands while the ConfigFS-managed nexus is being created, not yet available, or has just been removed.
4. Cause vulnerable kernel paths such as bot_submit_command() or related transfer handlers to dereference a NULL tpg->tpg_nexus pointer.
5. Crash the kernel, resulting in denial of service, reboot, or loss of availability.

How to detect it

To determine whether exploitation or attempted triggering already occurred, review kernel logs and crash artifacts rather than application logs. Useful sources include journalctl -k, dmesg history, /var/log/kern.log, /var/log/messages, systemd-journald persistent logs, pstore/ramoops records under /sys/fs/pstore, kdump/vmcore files, appliance crash reports, and out-of-band management reboot records. Look for kernel oops or panic events that mention NULL pointer dereference, USB gadget, f_tcm, BOT command handling, target core, ConfigFS gadget changes, or stack traces containing bot_submit_command() or related f_tcm functions. Correlate crashes with USB connect/disconnect events, ConfigFS gadget reconfiguration, creation or removal of target nexus settings, and unexpected host-side BOT traffic. Because the primary outcome is a crash, absence of logs may occur if persistent kernel logging or crash dump capture was not enabled before the event.

• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing: Fatal exception
• bot_submit_command
• bot_send_bad_response
• usbg_submit_command
• f_tcm
• tpg_nexus
• tvn_se_sess
• USB gadget
• Bulk-Only Transport
• BOT command
• /sys/kernel/config/usb_gadget
• /sys/fs/pstore
• dmesg:.*NULL pointer dereference.*bot_submit_command
• journalctl -k:.*f_tcm

What your security team should do

• Prioritize patching systems that operate in USB gadget mode, especially embedded, appliance, OT, kiosk, edge, or lab devices with accessible USB connections.
• Inventory Linux devices using ConfigFS USB gadget configurations and identify any use of the f_tcm USB Target driver.
• Disable f_tcm or broader USB gadget target functionality where it is not required.
• Restrict physical and logical access to USB ports that can act as a host to vulnerable gadget devices.
• Collect and retain kernel logs, pstore/ramoops data, and kdump crash dumps from exposed devices to support post-crash analysis.
• Monitor for recurring kernel panics or NULL pointer dereferences involving f_tcm, bot_submit_command, or USB gadget storage paths.
• Coordinate with Linux distribution or device vendors for fixed kernel packages where upstream kernel version mapping is not directly managed internally.