OESA-2026-2173

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

icmp: fix NULL pointer dereference in icmptagvalidation()

icmptagvalidation() unconditionally dereferences the result of rcudereference(inetprotos[proto]) without checking for NULL. The inetprotos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ipnopmtudisc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context.

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmpunreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: <IRQ> icmprcv (net/ipv4/icmp.c:1527) ipprotocoldeliverrcu (net/ipv4/ipinput.c:207) iplocaldeliverfinish (net/ipv4/ipinput.c:242) iplocaldeliver (net/ipv4/ipinput.c:262) iprcv (net/ipv4/ip_input.c:573) __netifreceiveskbonecore (net/core/dev.c:6164) processbacklog (net/core/dev.c:6628) handlesoftirqs (kernel/softirq.c:561) </IRQ>

Add a NULL check before accessing icmpstricttag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.(CVE-2026-23398)

In the Linux kernel, the following vulnerability has been resolved:

net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check

The same bounds-check bug fixed for NDP16 in the previous patch also exists in cdcncmrxverifyndp32(). The DPE array size is validated against the total skb length without accounting for ndpoffset, allowing out-of-bounds reads when the NDP32 is placed near the end of the NTB.

Add ndpoffset to the nframes bounds check and use structsizet() to express the NDP-plus-DPE-array size more clearly.

Compile-tested only.(CVE-2026-23447)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: teql: Fix double-free in teqlmasterxmit

Whenever a TEQL devices has a lockless Qdisc as root, qdiscreset should be called using the seqlock to avoid racing with the datapath. Failure to do so may cause crashes like the following:

[ 238.028993][ T318] BUG: KASAN: double-free in skbreleasedata (net/core/skbuff.c:1139) [ 238.029328][ T318] Free of addr ffff88810c67ec00 by task pocteqluafke/318 [ 238.029749][ T318] [ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: pocteqlke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full) [ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 238.029910][ T318] Call Trace: [ 238.029913][ T318] <TASK> [ 238.029916][ T318] dumpstacklvl (lib/dumpstack.c:122) [ 238.029928][ T318] printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 238.029940][ T318] ? skbreleasedata (net/core/skbuff.c:1139) [ 238.029944][ T318] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) ... [ 238.029957][ T318] ? skbreleasedata (net/core/skbuff.c:1139) [ 238.029969][ T318] kasanreportinvalidfree (mm/kasan/report.c:221 mm/kasan/report.c:563) [ 238.029979][ T318] ? skbreleasedata (net/core/skbuff.c:1139) [ 238.029989][ T318] checkslaballocation (mm/kasan/common.c:231) [ 238.029995][ T318] kmemcachefree (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1)) [ 238.030004][ T318] skbreleasedata (net/core/skbuff.c:1139) ... [ 238.030025][ T318] skskbreasondrop (net/core/skbuff.c:1256) [ 238.030032][ T318] pfifofastreset (./include/linux/ptrring.h:171 ./include/linux/ptrring.h:309 ./include/linux/skbarray.h:98 net/sched/schgeneric.c:827) [ 238.030039][ T318] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) ... [ 238.030054][ T318] qdiscreset (net/sched/schgeneric.c:1034) [ 238.030062][ T318] teqldestroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157) [ 238.030071][ T318] __qdiscdestroy (./include/net/pktsched.h:328 net/sched/schgeneric.c:1077) [ 238.030077][ T318] qdiscgraft (net/sched/schapi.c:1062 net/sched/schapi.c:1053 net/sched/sch_api.c:1159) [ 238.030089][ T318] ? __pfxqdiscgraft (net/sched/schapi.c:1091) [ 238.030095][ T318] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 238.030102][ T318] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 238.030106][ T318] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 238.030114][ T318] tcgetqdisc (net/sched/schapi.c:1529 net/sched/schapi.c:1556) ... [ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s: [ 238.073392][ T318] kasansavestack (mm/kasan/common.c:58) [ 238.073884][ T318] kasansavetrack (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.074230][ T318] __kasanslaballoc (mm/kasan/common.c:369) [ 238.074578][ T318] kmem_cacheallocnodenoprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921) [ 238.076091][ T318] kmallocreserve (net/core/skbuff.c:616 (discriminator 107)) [ 238.076450][ T318] __allocskb (net/core/skbuff.c:713) [ 238.076834][ T318] allocskbwithfrags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763) [ 238.077178][ T318] sockallocsendpskb (net/core/sock.c:2997) [ 238.077520][ T318] packetsendmsg (net/packet/afpacket.c:2926 net/packet/afpacket.c:3019 net/packet/afpacket.c:3108) [ 238.081469][ T318] [ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s: [ 238.082761][ T318] kasansavestack (mm/kasan/common.c:58) [ 238.083481][ T318] kasansavetrack (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.085348][ T318] kasansavefreeinfo (mm/kasan/generic.c:587 (discriminator 1)) [ 238.085900][ T318] __kasanslabfree (mm/ ---truncated---(CVE-2026-23449)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconntrackh323: check for zero length in DecodeQ931()

In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read.

Add a check to ensure len is positive after the decrement.(CVE-2026-23455)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconntrackh323: fix OOB read in decode_int() CONS case

In decodeint(), the CONS case calls getbits(bs, 2) to read a length value, then calls getuint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for getbits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read.

Add a boundary check for len bytes after getbits() and before getuint().(CVE-2026-23456)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconntracksip: fix Content-Length u32 truncation in siphelptcp()

siphelptcp() parses the SIP Content-Length header with simplestrtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINTMAX are silently truncated before computing the SIP message boundary.

For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser.

Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.(CVE-2026-23457)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: fix use-after-free in ctnetlinkdumpexp_ct()

ctnetlinkdumpexpct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlinkexpctdumptable(), but drops the conntrack reference immediately after netlinkdumpstart(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfcthelp(ct), leading to a use-after-free on ct->ext.

The bug is that the netlinkdumpcontrol has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlinkgetconntrack) properly use .start/.done callbacks for this purpose.

Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily.

BUG: KASAN: slab-use-after-free in ctnetlinkexpctdumptable+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133

CPU: 1 UID: 0 PID: 133 Comm: ctnetlinkpoc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: <TASK> ctnetlinkexpctdumptable+0x4f/0x2e0 netlinkdump+0x333/0x880 netlinkrecvmsg+0x3e2/0x4b0 ? aaskperm+0x184/0x450 sockrecvmsg+0xde/0xf0

Allocated by task 133: kmemcachealloc_noprof+0x134/0x440 __nfconntrackalloc+0xa8/0x2b0 ctnetlinkcreateconntrack+0xa1/0x900 ctnetlinknewconntrack+0x3cf/0x7d0 nfnetlinkrcvmsg+0x48e/0x510 netlinkrcvskb+0xc9/0x1f0 nfnetlinkrcv+0xdb/0x220 netlinkunicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 _syssendmsg+0xf4/0x180

Freed by task 0: slabfreeafterrcudebug+0xad/0x1e0 rcu_core+0x5c3/0x9c0(CVE-2026-23458)

In the Linux kernel, the following vulnerability has been resolved:

spi: fix use-after-free on controller registration failure

Make sure to deregister from driver core also in the unlikely event that per-cpu statistics allocation fails during controller registration to avoid use-after-free (of driver resources) and unclocked register accesses.(CVE-2026-31389)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: avoid overflows in ip6datagramsend_ctl()

Yiming Qian reported : <quote> I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via skb_under_panic() (local DoS).

The core issue is a mismatch between:

• a 16-bit length accumulator (struct ipv6_txoptions::opt_flen, type __u16) and

• a pointer to the last provided destination-options header (opt->dst1opt)

  when multiple IPV6_DSTOPTS control messages (cmsgs) are provided.

• include/net/ipv6.h:

  • struct ipv6_txoptions::opt_flen is __u16 (wrap possible). (lines 291-307, especially 298)
• net/ipv6/datagram.c:ip6_datagram_send_ctl():
  • Accepts repeated IPV6_DSTOPTS and accumulates into opt_flen without rejecting duplicates. (lines 909-933)
• net/ipv6/ip6_output.c:__ip6_append_data():
  • Uses opt->opt_flen + opt->opt_nflen to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465)
• net/ipv6/ip6_output.c:__ip6_make_skb():
  • Calls ipv6_push_frag_opts() if opt->opt_flen is non-zero. (lines 1930-1934)
• net/ipv6/exthdrs.c:ipv6_push_frag_opts() / ipv6_push_exthdr():
  • Push size comes from ipv6_optlen(opt->dst1opt) (based on the pointed-to header). (lines 1179-1185 and 1206-1211)

1. opt_flen is a 16-bit accumulator:

• include/net/ipv6.h:298 defines __u16 opt_flen; /* after fragment hdr */.

2. ip6_datagram_send_ctl() accepts repeated IPV6_DSTOPTS cmsgs and increments opt_flen each time:

• In net/ipv6/datagram.c:909-933, for IPV6_DSTOPTS:

  • It computes len = ((hdr->hdrlen + 1) << 3);
  • It checks CAP_NET_RAW using ns_capable(net->user_ns, CAP_NET_RAW). (line 922)
  • Then it does:
    • opt->opt_flen += len; (line 927)
    • opt->dst1opt = hdr; (line 928)

  There is no duplicate rejection here (unlike the legacy IPV6_2292DSTOPTS path which rejects duplicates at net/ipv6/datagram.c:901-904).

  If enough large IPV6_DSTOPTS cmsgs are provided, opt_flen wraps while dst1opt still points to a large (2048-byte) destination-options header.

  In the attached PoC (poc.c):

• 32 cmsgs with hdrlen=255 => len = (255+1)*8 = 2048

• 1 cmsg with hdrlen=0 => len = 8
• Total increment: 32*2048 + 8 = 65544, so (__u16)opt_flen == 8
• The last cmsg is 2048 bytes, so dst1opt points to a 2048-byte header.

3. The transmit path sizes headers using the wrapped opt_flen:

• In net/ipv6/ip6_output.c:1463-1465:

  • headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;

  With wrapped opt_flen, headersize/headroom decisions underestimate what will be pushed later.

  4. When building the final skb, the actual push length comes from dst1opt and is not limited by wrapped opt_flen:
  • In net/ipv6/ip6_output.c:1930-1934:
    • if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);
  • In net/ipv6/exthdrs.c:1206-1211, ipv6_push_frag_opts() pushes dst1opt via ipv6_push_exthdr().
  • In net/ipv6/exthdrs.c:1179-1184, ipv6_push_exthdr() does:
    • skb_push(skb, ipv6_optlen(opt));
    • memcpy(h, opt, ipv6_optlen(opt));

  With insufficient headroom, skb_push() underflows and triggers skb_under_panic() -> BUG():

  • net/core/skbuff.c:2669-2675 (skb_push() calls skb_under_panic())

  • net/core/skbuff.c:207-214 (skb_panic() ends in BUG())

  • The IPV6_DSTOPTS cmsg path requires CAP_NET_RAW in the target netns user namespace (ns_capable(net->user_ns, CAP_NET_RAW)).

  • Root (or any task with CAP_NET_RAW) can trigger this without user namespaces.

  • An unprivileged uid=1000 user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced CAP_NET_RAW (the attached PoC does this).

  • Local denial of service: kernel BUG/panic (system crash). - ---truncated---(CVE-2026-31415)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnetlink_log: account for netlink header size

This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size.

This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.(CVE-2026-31416)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconntracksip: fix use of uninitialized rtpaddr in processsdp

processsdp() declares union nfinetaddr rtpaddr on the stack and passes it to the nfnatsip sdpsession hook after walking the SDP media descriptions. However rtpaddr is only initialized inside the media loop when a recognized media type with a non-zero port is found.

If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtpaddr is never assigned. Despite that, the function still calls hooks->sdpsession() with &rtpaddr, causing nfnatsdpsession() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it.

With CONFIGINITSTACKALLZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack.

Fix this by pre-initializing rtpaddr from the session-level connection address (caddr) when available, and tracking via a havertpaddr flag whether any valid address was established. Skip the sdpsession hook entirely when no valid address exists.(CVE-2026-31427)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnetlinklog: fix uninitialized padding leak in NFULAPAYLOAD

_buildpacketmessage() manually constructs the NFULAPAYLOAD netlink attribute using skbput() and skbcopybits(), bypassing the standard nlareserve()/nlaput() helpers. While nlatotalsize(datalen) bytes are allocated (including NLA alignment padding), only datalen bytes of actual packet data are copied. The trailing nlapadlen(datalen) bytes (1-3 when datalen is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket.

Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via _nlareserve(). The subsequent skbcopybits() fills in the payload data on top of the properly initialized attribute.(CVE-2026-31428)

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algifaead - Revert to operating out-of-place\n\nThis mostly reverts commit 72548b093ee3 except for the copying of the associated data.\n\nThere is no benefit in operating in-place in algifaead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.(CVE-2026-31431)