crypto: algifaead - Revert to operating out-of-place

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

xfrmuser: fix info leak in buildmapping()

struct xfrmusersaid has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.

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

netfilter: nfnetlinklog: initialize nfgenmsg in NLMSGDONE terminator

When batching multiple NFLOG messages (inst->qlen > 1), nfulnlsend() appends an NLMSGDONE terminator with sizeof(struct nfgenmsg) payload via nlmsgput(), but never initializes the nfgenmsg bytes. The nlmsgput() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSGDONE message body.

Use nfnlmsgput() to build the NLMSGDONE terminator, which initializes the nfgenmsg payload via nfnlfillhdr(), consistent with how buildpacketmessage() already constructs NFULNLMSGPACKET headers.

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

netfilter: xtmultiport: validate range encoding in checkentry

portsmatchv1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.

The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving portsmatchv1() to step past the last valid ports[] element while interpreting the rule.

Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.

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

nftables: nftdynset: fix possible stateful expression memleak in error path

If cloning the second stateful expression in the element via GFPATOMIC fails, then the first stateful expression remains in place without being released.

unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm "softirq", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpuallocnoprof+0x453/0xd80       nftcounterclone+0x9c/0x190 [nftables]       nftexprclone+0x8f/0x1b0 [nftables]       nftdynsetnew+0x2cb/0x5f0 [nftables]       nftrhashupdate+0x236/0x11c0 [nftables]       nftdynseteval+0x11f/0x670 [nftables]       nftdochain+0x253/0x1700 [nftables]       nftdochainipv4+0x18d/0x270 [nftables]       nfhookslow+0xaa/0x1e0       iplocaldeliver+0x209/0x330

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

net: ipv6: ndisc: fix ndiscrauseropt to initialize nduseroptpadX fields to zero to prevent an info-leak

When processing Router Advertisements with user options the kernel builds an RTMNEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data

The fix is simple, just zeroes the padding fields.

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

ipv6: icmp: clear skb2->cb[] in ip6errgenicmpv6unreach()

Sashiko AI-review observed:

In ip6errgenicmpv6unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inetskbparm. When skb is cloned into skb2 and passed to icmp6send(), it uses IP6CB(skb2).

IP6CB interprets the IPv4 inetskbparm as an inet6skbparm. The cipso offset in inetskbparm.opt directly overlaps with dsthao in inet6skbparm at offset 18.

If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6send(), mip6addrswap() is called and uses ipv6findtlv(skb, opt->dsthao, IPV6TLVHAO).

This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6destopthao.

Could mip6addrswap() then perform a 16-byte swap that extends past the end of the packet data into skbsharedinfo?

Should the cb array also be cleared in ip6errgenicmpv6unreach() and ip6ip6err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6err() needs to be changed. A separate patch would be better anyway.

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

net: sched: clsapi: fix tcchainfillnode to initialize tcminfo to zero to prevent an info-leak

When building netlink messages, tcchainfillnode() never initializes the tcminfo field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field.

The fix simply zeroes tcminfo alongside the other fields that are already initialized.

crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption

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

bpf: Fix regsafe() for pointers to packet

In case rold->reg->range == BEYONDPKTEND && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.

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

netfilter: xtables: ensure names are nul-terminated

Reject names that lack a \0 character before feeding them to functions that expect c-strings.

Fixes tag is the most recent commit that needs this change.

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

netfilter: nfconntrackhelper: pass helper to expect cleanup

nfconntrackhelperunregister() calls nfctexpectiteratedestroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expectiterme() never matches any expectation and all of them survive the cleanup.

After unregister returns, nfnlcthelperdel() frees the helper object immediately. Subsequent expectation dumps or packet-driven initconntrack() calls then dereference the freed exp->helper, causing a use-after-free.

Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed.

BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seqprintf+0x17a/0x240 expseqshow+0x2e5/0x560 seqreaditer+0x419/0x1280 procregread+0x1ac/0x270 vfsread+0x179/0x930 ksysread+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)

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

netfilter: ctnetlink: zero expect NAT fields when CTAEXPECTNAT absent

ctnetlinkallocexpect() allocates expectations from a non-zeroing slab cache via nfctexpectalloc(). When CTAEXPECTNAT is not present in the netlink message, savedaddr and savedproto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlinkexpdumpexpect(), which checks these fields to decide whether to emit CTAEXPECTNAT.

The safe sibling nfctexpectinit(), used by the packet path, explicitly zeroes these fields.

Zero savedaddr, savedproto and dir in the else branch, guarded by ISENABLED(CONFIGNFNAT) since these fields only exist when NAT is enabled.

Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTAEXPECTNAT, and observing that the ctnetlink dump emits a spurious CTAEXPECTNAT containing stale data from the prior allocation.

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

netfilter: ctnetlink: ignore explicit helper on new expectations

Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation.

This was uncovered when validating CTAEXPECTCLASS via different helper provided by userspace than the existing master conntrack helper:

BUG: KASAN: slab-out-of-bounds in nfctexpectrelatedreport+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nfctexpectrelatedreport+0x2479/0x27c0 ctnetlinkcreateexpect+0x22b/0x3b0 ctnetlinknewexpect+0x4bd/0x5c0 nfnetlinkrcvmsg+0x67a/0x950 netlinkrcvskb+0x120/0x350

Allowing to read kernel memory bytes off the expectation boundary.

CTAEXPECTHELPNAME is still used to offer the helper name to userspace via netlink dump.

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

netfilter: nftables: reject immediate NFQUEUE verdict

nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NFQUEUE immediate verdicts to address this issue.

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

net/x25: Fix potential double free of skb

When allocskb fails in x25queuerxframe it calls kfreeskb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain:

x25queuerxframe returns 1 | v x25state3machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25processrxframe returns queued=0 | v x25backlogrcv at line 452 sees queued=0 and calls kfreeskb(skb) again

This would free the same skb twice. Looking at x25backlogrcv:

net/x25/x25in.c:x25backlogrcv() { ... queued = x25processrxframe(sk, skb); ... if (!queued) kfreeskb(skb); }

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

iio: adc: ti-adc161s626: use DMA-safe memory for spiread()

Add a DMA-safe buffer and use it for spiread() instead of a stack memory. All SPI buffers must be DMA-safe.

Since we only need up to 3 bytes, we just use a u8[] instead of be16 and be32 and change the conversion functions appropriately.

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

iio: gyro: mpu3050: Move iiodeviceregister() to correct location

iiodeviceregister() should be at the end of the probe function to prevent race conditions.

Place iiodeviceregister() at the end of the probe function and place iiodeviceunregister() accordingly.

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

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.

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

net: ftgmac100: fix ring allocation unwind on open failure

ftgmac100allocrings() allocates rxskbs, txskbs, rxdes, txdes, and rxscratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function.

Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.

bridge: brndsend: linearize skb before parsing ND options

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

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

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

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

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

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

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

xfrmuser: fix info leak in buildreport()

struct xfrmuserreport is a u8 proto field followed by a struct xfrmselector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.

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

net: rfkill: prevent unlimited numbers of rfkill events from being created

Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a "large" number (i.e. 1000) to prevent abuses like this.

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

mptcp: fix slab-use-after-free in inetlookupestablished

The ehash table lookups are lockless and rely on SLABTYPESAFEBYRCU to guarantee socket memory stability during RCU read-side critical sections. Both tcpprot and tcpv6prot have their slab caches created with this flag via protoregister().

However, MPTCP's mptcpsubflowinit() copies tcpv6prot into tcpv6protoverride during inetinit() (fsinitcall, level 5), before inet6init() (moduleinit/deviceinitcall, level 6) has called protoregister(&tcpv6prot). At that point, tcpv6prot.slab is still NULL, so tcpv6protoverride.slab remains NULL permanently.

This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLABTYPESAFEBYRCU, so when these sockets are freed without SOCKRCUFREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcureadlock can then access freed memory, triggering a slab-use-after-free in inetlookupestablished.

Fix this by splitting the IPv6-specific initialization out of mptcpsubflowinit() into a new mptcpsubflowv6init(), called from mptcpprotov6init() before protocol registration. This ensures tcpv6protoverride.slab correctly inherits the SLABTYPESAFEBYRCU slab cache.

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

netfilter: nftct: fix use-after-free in timeout object destroy

nftcttimeoutobjdestroy() frees the timeout object with kfree() immediately after nfctuntimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcudereference() in nfcttimeoutdata().

Add an rcuhead to struct nfcttimeout and use kfreercu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlinkcttimeout.c.

KASAN report: BUG: KASAN: slab-use-after-free in nfconntracktcppacket+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80

Call Trace: nfconntracktcppacket+0x1381/0x29d0 nfconntrackin+0x612/0x8b0 nfhookslow+0x70/0x100 iplocalout+0x1b2/0x210 tcpsendmsglocked+0x722/0x1580 syssendto+0x2d8/0x320

Allocated by task 75: nftcttimeoutobjinit+0xf6/0x290 nftobjinit+0x107/0x1b0 nftablesnewobj+0x680/0x9c0 nfnetlinkrcvbatch+0xc29/0xe00

Freed by task 26: nftobjdestroy+0x3f/0xa0 nftablestransdestroywork+0x51c/0x5c0 processonework+0x2c4/0x5a0

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

xfrm: clear trailing padding in buildpolexpire()

buildexpire() clears the trailing padding bytes of struct xfrmuserexpire after setting the hard field via memsetafter(), but the analogous function buildpolexpire() does not do this for struct xfrmuserpolexpire.

The padding bytes after the u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRPEXPIRE listeners, leaking kernel heap memory contents.

Add the missing memsetafter() call, matching buildexpire().

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

net: altera-tse: fix skb leak on DMA mapping error in tsestartxmit()

When dmamapsingle() fails in tsestartxmit(), the function returns NETDEVTXOK without freeing the skb. Since NETDEVTXOK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure.

Add devkfreeskbany() before returning to properly free the skb.

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

mmc: vub300: fix NULL-deref on disconnect

Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.

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

net: stmmac: fix integer underflow in chain mode

The jumbofrm() chain-mode implementation unconditionally computes

len = nopagedlen - bmax;

where nopagedlen = skbheadlen(skb) (linear bytes only) and bmax is BUFSIZE8KiB or BUFSIZE2KiB. However, the caller stmmacxmit() decides to invoke jumbofrm() based on skb->len (total length including page fragments):

isjumbo = stmmacisjumbofrm(priv, skb->len, enhdesc);

When a packet has a small linear portion (nopagedlen <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax i pointers far beyond the skb buffer to dmamapsingle(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware.

Fix this by introducing a buflen local variable clamped to min(nopagedlen, bmax). Computing len = nopagedlen - buflen is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmacxmit() handles page fragments afterward.