CVE-2026-89780: net: qualcomm: rmnet: restore skb->dev on deaggregated frames
In the Linux kernel, the following vulnerability has been resolved:
net: qualcomm: rmnet: restore skb->dev on deaggregated frames
rmnetmapdeaggregate() allocates each sub-frame with allocskb() and leaves skb->dev NULL. rmnetmapingresshandler() assigns skb->dev = ep->egressdev only on the data path, but a MAP command frame is dispatched to rmnetmapcommand() before that, so rmnetmapsendack() runs netiftxlock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESSDEAGGREGATION and INGRESSMAPCOMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd.
Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnetmapdeaggregate() has a valid device.
BUG: KASAN: null-ptr-deref in rawspinlock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: rawspinlock (kernel/locking/spinlock.c:158) netiftxlock (net/sched/schgeneric.c:497) rmnetmapcommand (drivers/net/ethernet/qualcomm/rmnet/rmnetmapcommand.c:67) rmnetrxhandler (drivers/net/ethernet/qualcomm/rmnet/rmnethandlers.c:125) netifreceiveskbcore.constprop.0 (net/core/dev.c:6103) ... netifreceiveskbonecore (net/core/dev.c:6214) netifreceiveskb (net/core/dev.c:6474) tungetuser (drivers/net/tun.c:1966) tunchrwriteiter (drivers/net/tun.c:2012) vfswrite (fs/readwrite.c:687) ksyswrite (fs/readwrite.c:739) dosyscall64 (arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121) Kernel panic - not syncing: Fatal exception in interrupt
Affected Software
Event History
Frequently Asked Questions
What conditions must an attacker satisfy to trigger the flaw?
An unprivileged user must be able to create a user and network namespace, create an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS enabled, and write an aggregated frame containing a flow-control command to the tap file descriptor.
What is the observable impact when exploitation succeeds?
Processing the MAP command can call netif_tx_lock() with a NULL skb->dev value, causing a NULL-pointer dereference. The reported failure is a KASAN null-pointer dereference in _raw_spin_lock during rmnet_map_command().
How can the issue be identified from crash diagnostics?
Affected crashes show a NULL-pointer dereference in _raw_spin_lock, with a call chain including netif_tx_lock(), rmnet_map_command(), and rmnet_rx_handler(). The fault is caused by a deaggregated frame reaching command handling without a valid skb->dev assignment.