CVE-2026-18415: Out-of-bounds write in the IEEE 802.15.4 L2 transmit path for oversized non-6LoWPAN frames
ieee802154send() in subsys/net/l2/ieee802154/ieee802154.c copies the outgoing packet into a single fixed 125-byte transmit buffer (txframebufpool, sized IEEE802154MTU). In builds with CONFIGNETL2IEEE802154FRAGMENT enabled (the default whenever CONFIGNET6LO is set), the branch taken when 6LoWPAN fragmentation is not required performed an unchecked netbufaddmem(framebuf, pktbuf->data, pktbuf->len). The only guard was ASSERTNOMSG() inside netbufsimpleadd(), which is compiled out without CONFIGASSERT, so an oversized packet silently overran the frame buffer.
The defect is not reachable from the radio: for NETAFINET6 packets ieee8021546loencodepkt() compares the whole packet length against IEEE802154MTU and takes the fragmentation path when it does not fit, so every buffer copied on the unfragmented branch is within bounds. It is reachable through NETAFPACKET sockets bound to an 802.15.4 interface: for NETSOCKRAW the 6LoWPAN block is skipped entirely and for NETSOCKDGRAM it returns early on the address-family test, leaving no length validation anywhere on the transmit path (netcontextsendto() and netiftx() apply none, and pktbufferlength() does not clamp the allocation for this L2).
An application — or, in a CONFIGUSERSPACE build, an unprivileged application thread using the zsocksocket()/zsocksendto() syscalls — can therefore drive a supervisor-mode out-of-bounds write of chosen bytes past the 125-byte pool buffer. With the default CONFIGNETBUFFIXEDDATASIZE of 128 bytes the overrun is bounded to roughly llhdrlen + 3 bytes; with CONFIGNETBUFVARIABLEDATASIZE a single storage buffer can be as large as CONFIGNETPKTBUFTXDATAPOOLSIZE, making the overrun far larger. The consequence is corruption of memory adjacent to the pool, with a crash or further compromise of kernel state as the practical impact.
The fix validates llhdrlen + netpktgetlen(pkt) + authtaglen against IEEE802154MTU before any copy and adds a tailroom-checking copypkttoframe() helper that returns -EMSGSIZE instead of overrunning the buffer. The same change also linearizes the whole netbuf chain into one MAC frame, so packet storage boundaries no longer become frame boundaries on the wire.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to the reachable transmit path?
The reachable path requires an 802.15.4 interface and NET_AF_PACKET socket use against that interface. Builds with CONFIG_NET_L2_IEEE802154_FRAGMENT enabled are affected; this is the default when CONFIG_NET_6LO is set.
Can a received 802.15.4 radio frame trigger the overwrite?
No. The defect is not reachable from the radio. IPv6 packets use the 6LoWPAN encoding path, which compares the whole packet length with IEEE802154_MTU and fragments packets that do not fit.
What packet-socket cases lack the relevant length check?
NET_SOCK_RAW packet sockets skip the 6LoWPAN block entirely. NET_SOCK_DGRAM packet sockets return early on the address-family test, leaving no transmit-path length validation before data is copied into the fixed transmit buffer.
Does enabling assertions change the behavior?
The only buffer-size guard was an __ASSERT_NO_MSG() in net_buf_simple_add(). Without CONFIG_ASSERT, that assertion is compiled out and an oversized packet can silently overrun the buffer.