OESA-2026-2236

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

netfilter: conntrack: add missing netlink policy validations

Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.

These attributes are used by the kernel without any validation. Extend the netlink policies accordingly.

Quoting the reporter: nlattrtosctp() assigns the user-supplied CTAPROTOINFOSCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..]

and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.(CVE-2026-31407)

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

netfilter: ipset: drop logically empty buckets in mtype_del

mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots.

Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.(CVE-2026-31418)

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

bridge: mrp: reject zero test interval to avoid OOM panic

brmrpstarttest() and brmrpstartintest() accept the user-supplied interval value from netlink without validation. When interval is 0, usecstojiffies(0) yields 0, causing the delayed work (brmrptestworkexpired / brmrpintestworkexpired) to reschedule itself with zero delay. This creates a tight loop on systempercpuwq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock.

The same zero-interval issue applies to brmrpstartintest_parse() for interconnect test frames.

Use NLAPOLICYMIN(NLAU32, 1) in the nlapolicy tables for both IFLABRIDGEMRPSTARTTESTINTERVAL and IFLABRIDGEMRPSTARTINTESTINTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (brfdb, br_mst) enforce range constraints on netlink attributes.(CVE-2026-31420)

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

net/sched: schhfsc: fix divide-by-zero in rtscmin()

m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable dsm and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path:

Oops: divide error: 0000 RIP: 0010:rtscmin (net/sched/schhfsc.c:601) Call Trace: inited (net/sched/schhfsc.c:629) hfscenqueue (net/sched/schhfsc.c:1569) [...]

Widen dsm to u64 and replace dodiv() with div64u64() so the full difference is preserved.(CVE-2026-31423)

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

netfilter: xtables: restrict xtcheckmatch/xtchecktarget extensions for NFPROTOARP

Weiming Shi says:

xtmatch and xttarget structs registered with NFPROTOUNSPEC can be loaded by any protocol family through nftcompat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NFINET* constants. This is only correct for families whose hook layout matches NFINET*: IPv4, IPv6, INET, and bridge all share the same five hooks (PREROUTING ... POSTROUTING).

ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NFARPOUT == 1 == NFINETLOCALIN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xtdevgroup is one concrete example:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroupmt+0xff/0x350 Call Trace: <TASK> nftmatcheval (net/netfilter/nftcompat.c:407) nftdochain (net/netfilter/nftablescore.c:285) nftdochainarp (net/netfilter/nftchainfilter.c:61) nfhookslow (net/netfilter/core.c:623) arpxmit (net/ipv4/arp.c:666) </TASK> Kernel panic - not syncing: Fatal exception in interrupt

Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports:

• arpt_CLASSIFY
• arpt_mangle
• arpt_MARK

that provide explicit NFPROTO_ARP match/target declarations.(CVE-2026-31424)

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

ALSA: ctxfi: Limit PTP to a single page

Commit 391e69143d0a increased CTPTPNUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic.

ctvmmap() always uses PTEs in vm->ptp[0].area regardless of CTPTPNUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ctvmmap() tries to access beyond the allocated space and causes a page fault:

BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ctvmmap+0x17c/0x280 [sndctxfi] Call Trace: atcpcmplaybackprepare+0x225/0x3b0 ctpcmplaybackprepare+0x38/0x60 sndpcmdoprepare+0x2f/0x50 sndpcmactionsingle+0x36/0x90 sndpcmactionnonatomic+0xbf/0xd0 sndpcmioctl+0x28/0x40 __x64sysioctl+0x97/0xe0 dosyscall64+0x81/0x610 entrySYSCALL64afterhwframe+0x76/0x7e

Revert CTPTPNUM to 1. The 256 SRCRESOURCENUM and playback_count remain unchanged.(CVE-2026-31602)

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

net: ipv6: flowlabel: defer exclusive option free until RCU teardown

ip6fl_seq_show() walks the global flowlabel hash under the seq-file RCU read-side lock and prints fl->opt->opt_nflen when an option block is present.

Exclusive flowlabels currently free fl->opt as soon as fl->users drops to zero in fl_release(). However, the surrounding struct ip6_flowlabel remains visible in the global hash table until later garbage collection removes it and fl_free_rcu() finally tears it down.

A concurrent /proc/net/ip6_flowlabel reader can therefore race that early kfree() and dereference freed option state, triggering a crash in ip6fl_seq_show().

Fix this by keeping fl->opt alive until fl_free_rcu(). That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.(CVE-2026-31680)

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

perf/x86: Fix potential bad containerof in intelpmuhwconfig

Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86hybridpmu and a containerof operation in intelpmusetacrcausedconstr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intelpmusetacrcausedconstr with an isx86_event check.(CVE-2026-31782)