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

netfilter: nftables: clone set on flush only

Syzbot with fault injection triggered a failing memory allocation with GFPKERNEL which results in a WARN splat:

iter.err WARNING: net/netfilter/nftablesapi.c:845 at nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845, CPU#0: syz.0.17/5992 Modules linked in: CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845 Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43 +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9 RSP: 0018:ffffc900045af780 EFLAGS: 00010293 RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40 RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000 RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0 R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920 FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0 Call Trace: <TASK> nftreleasetable+0xceb/0x11f0 net/netfilter/nftablesapi.c:12115 nftrcvnlevent+0xc25/0xdb0 net/netfilter/nftablesapi.c:12187 notifiercallchain+0x19d/0x3a0 kernel/notifier.c:85 blockingnotifiercallchain+0x6a/0x90 kernel/notifier.c:380 netlinkrelease+0x123b/0x1ad0 net/netlink/afnetlink.c:761 sockrelease net/socket.c:662 [inline] sockclose+0xc3/0x240 net/socket.c:1455

Restrict set clone to the flush set command in the preparation phase. Add NFTITERUPDATECLONE and use it for this purpose, update the rbtree and pipapo backends to only clone the set when this iteration type is used.

As for the existing NFTITERUPDATE type, update the pipapo backend to use the existing set clone if available, otherwise use the existing set representation. After this update, there is no need to clone a set that is being deleted, this includes bound anonymous set.

An alternative approach to NFTITERUPDATECLONE is to add a .clone interface and call it from the flush set path.

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:

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:

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:

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:

rxrpc: fix reference count leak in rxrpcserverkeyring()

This patch fixes a reference count leak in rxrpcserverkeyring() by checking if rx->securities is already set.

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

RDMA/irdma: Fix deadlock during netdev reset with active connections

Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering devicedelete and subsequent client removal. During client removal, uverbsclient waits for QP reference count to reach zero while cmaclient holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.

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

net: bonding: fix NULL deref in bonddebugrlbhashshow

rlbclearslave intentionally keeps RLB hash-table entries on the rxhashtblusedhead list with slave set to NULL when no replacement slave is available. However, bonddebugrlbhashshow visites clientinfo->slave without checking if it's NULL.

Other used-list iterators in bondalb.c already handle this NULL-slave state safely:

- rlbupdateclient returns early on !clientinfo->slave - rlbrequpdateslaveclients, rlbclearslave, and rlbrebalance compare slave values before visiting - lbrequpdatesubnetclients continues if slave is NULL

The following NULL deref crash can be trigger in bonddebugrlbhashshow:

[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bonddebugrlbhashshow (drivers/net/bonding/bonddebugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seqreaditer (fs/seqfile.c:231) [ 1.296341] seqread (fs/seqfile.c:164) [ 1.296493] fullproxyread (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfsread (fs/readwrite.c:572) [ 1.296981] ksysread (fs/readwrite.c:717) [ 1.297132] dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) [ 1.297325] entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Add a NULL check and print "(none)" for entries with no assigned slave.

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

udp: Fix wildcard bind conflict check when using hash2

When binding a udpsock to a local address and port, UDP uses two hashes (udptable->hash and udptable->hash2) for collision detection. The current code switches to "hash2" when hslot->count > 10.

"hash2" is keyed by local address and local port. "hash" is keyed by local port only.

The issue can be shown in the following bind sequence (pseudo code):

bind(fd1, "[fd00::1]:8888") bind(fd2, "[fd00::2]:8888") bind(fd3, "[fd00::3]:8888") bind(fd4, "[fd00::4]:8888") bind(fd5, "[fd00::5]:8888") bind(fd6, "[fd00::6]:8888") bind(fd7, "[fd00::7]:8888") bind(fd8, "[fd00::8]:8888") bind(fd9, "[fd00::9]:8888") bind(fd10, "[fd00::10]:8888")

/ Correctly return -EADDRINUSE because "hash" is used instead of "hash2". udpliblportinuse() detects the conflict. / bind(failfd, "[::]:8888")

/ After one more socket is bound to "[fd00::11]:8888", hslot->count exceeds 10 and "hash2" is used instead. / bind(fd11, "[fd00::11]:8888") bind(failfd, "[::]:8888") / succeeds unexpectedly /

The same issue applies to the IPv4 wildcard address "0.0.0.0" and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For example, if there are existing sockets bound to "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or "[::ffff:0.0.0.0]:8888" can also miss the conflict when hslot->count > 10.

TCP inetcskgetport() already has the correct check in inetusebhash2onbind(). Rename it to inetusehash2onbind() and move it to inethashtables.h so udp.c can reuse it in this fix.

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

netfilter: nfconntrackexpect: skip expectations in other netns via proc

Skip expectations that do not reside in this netns.

Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns's conntrack entries via proc").

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

netfilter: ctnetlink: use netlink policy range checks

Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors.

- CTAPROTOINFOTCPSTATE: reject values > TCPCONNTRACKSYNSENT2 at policy level, removing the manual >= TCPCONNTRACKMAX check. - CTAPROTOINFOTCPWSCALEORIGINAL/REPLY: reject values > TCPMAXWSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTAFILTERORIGFLAGS/REPLYFLAGS: use NLAPOLICYMASK with CTAFILTERFALL, removing the manual mask checks. - CTAEXPECTFLAGS: use NLAPOLICYMASK with NFCTEXPECTMASK, adding a new mask define grouping all valid expect flags.

Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.

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

ipv6: avoid overflows in ip6datagramsendctl()

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 skbunderpanic() (local DoS).

The core issue is a mismatch between:

- a 16-bit length accumulator (struct ipv6txoptions::optflen, type u16) and - a pointer to the last provided destination-options header (opt->dst1opt)

when multiple IPV6DSTOPTS control messages (cmsgs) are provided.

- include/net/ipv6.h: - struct ipv6txoptions::optflen is u16 (wrap possible). (lines 291-307, especially 298) - net/ipv6/datagram.c:ip6datagramsendctl(): - Accepts repeated IPV6DSTOPTS and accumulates into optflen without rejecting duplicates. (lines 909-933) - net/ipv6/ip6output.c:ip6appenddata(): - Uses opt->optflen + opt->optnflen to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - net/ipv6/ip6output.c:ip6makeskb(): - Calls ipv6pushfragopts() if opt->optflen is non-zero. (lines 1930-1934) - net/ipv6/exthdrs.c:ipv6pushfragopts() / ipv6pushexthdr(): - Push size comes from ipv6optlen(opt->dst1opt) (based on the pointed-to header). (lines 1179-1185 and 1206-1211)

1. optflen is a 16-bit accumulator:

- include/net/ipv6.h:298 defines u16 optflen; / after fragment hdr /.

2. ip6datagramsendctl() accepts repeated IPV6DSTOPTS cmsgs and increments optflen each time:

- In net/ipv6/datagram.c:909-933, for IPV6DSTOPTS: - It computes len = ((hdr->hdrlen + 1) << 3); - It checks CAPNETRAW using nscapable(net->userns, CAPNETRAW). (line 922) - Then it does: - opt->optflen += len; (line 927) - opt->dst1opt = hdr; (line 928)

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

If enough large IPV6DSTOPTS cmsgs are provided, optflen 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: 322048 + 8 = 65544, so (u16)optflen == 8 - The last cmsg is 2048 bytes, so dst1opt points to a 2048-byte header.

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

- In net/ipv6/ip6output.c:1463-1465: - headersize = sizeof(struct ipv6hdr) + (opt ? opt->optflen + opt->optnflen : 0) + ...;

With wrapped optflen, 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 optflen:

- In net/ipv6/ip6output.c:1930-1934: - if (opt->optflen) proto = ipv6pushfragopts(skb, opt, proto); - In net/ipv6/exthdrs.c:1206-1211, ipv6pushfragopts() pushes dst1opt via ipv6pushexthdr(). - In net/ipv6/exthdrs.c:1179-1184, ipv6pushexthdr() does: - skbpush(skb, ipv6optlen(opt)); - memcpy(h, opt, ipv6optlen(opt));

With insufficient headroom, skbpush() underflows and triggers skbunderpanic() -> BUG():

- net/core/skbuff.c:2669-2675 (skbpush() calls skbunderpanic()) - net/core/skbuff.c:207-214 (skbpanic() ends in BUG())

- The IPV6DSTOPTS cmsg path requires CAPNETRAW in the target netns user namespace (nscapable(net->userns, CAPNETRAW)). - Root (or any task with CAPNETRAW) 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 CAPNETRAW (the attached PoC does this).

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

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

net: atm: fix crash due to unvalidated vcc pointer in sigdsend()

Reproducer available at [1].

The ATM send path (sendmsg -> vccsendmsg -> sigdsend) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AFATMSVC, SOCKDGRAM, 0); ioctl(fd, ATMSIGDCTRL); // become ATM signaling daemon struct msghdr msg = { .msgiov = &iov, ... }; (unsigned long )(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigdenq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing findgetvcc() which validates the pointer by searching through vcchash (similar to how sigdclose() iterates over all VCCs), and acquires a reference via sockhold() if found.

Since struct atmvcc embeds struct sock as its first member, they share the same lifetime. Therefore using sockhold/sockput is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigdclose() which could mark the vcc with various flags (e.g., ATMVFRELEASED) after findgetvcc() returns. However, sockhold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

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

net: usb: aqc111: Do not perform PM inside suspend callback

syzbot reports "task hung in rpmresume"

This is caused by aqc111suspend calling the PM variant of its writecmd routine.

The simplified call trace looks like this:

rpmsuspend() usbsuspendboth() - here udev->dev.power.runtimestatus == RPMSUSPENDING aqc111suspend() - called for the usb device interface aqc111write32cmd() usbautopmgetinterface() pmruntimeresumeandget() rpmresume() - here we call rpmresume() on our parent rpmresume() - Here we wait for a status change that will never happen.

At this point we block another task which holds rtnllock and locks up the whole networking stack.

Fix this by replacing the writecmd calls with their nopm variants

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

udptunnel: fix NULL deref caused by udpsockcreate6 when CONFIGIPV6=n

When CONFIGIPV6 is disabled, the udpsockcreate6() function returns 0 (success) without actually creating a socket. Callers such as foucreate() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference.

The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:founladddoit (net/ipv4/foucore.c:590 net/ipv4/foucore.c:764) [...] Call Trace: <TASK> genlfamilyrcvmsgdoit.constprop.0 (net/netlink/genetlink.c:1114) genlrcvmsg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlinkrcvskb (net/netlink/afnetlink.c:2550) genlrcv (net/netlink/genetlink.c:1219) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) socksendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) syssendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) x64syssendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) entrySYSCALL64afterhwframe (net/arch/x86/entry/entry64.S:130)

This patch makes udpsockcreate6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.

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

net: mvpp2: guard flow control update with globaltxfc in buffer switching

mvpp2bmswitchbuffers() unconditionally calls mvpp2bmpoolupdateprivfc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2cm3read()/mvpp2cm3write(), which dereference priv->cm3base without any NULL check.

When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c ("dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree")), priv->cm3base remains NULL and priv->globaltxfc is false. Any operation that triggers mvpp2bmswitchbuffers(), for example an MTU change that crosses the jumbo frame threshold, will crash:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2cm3read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2bmpoolupdatefc+0x40/0x12c mvpp2bmpoolupdateprivfc+0x94/0xd8 mvpp2bmswitchbuffers.isra.0+0x80/0x1c0 mvpp2changemtu+0x140/0x380 devsetmtu+0x1c/0x38 devsetmtuext+0x78/0x118 devsetmtu+0x48/0xa8 devifsioc+0x21c/0x43c devioctl+0x2d8/0x42c sockioctl+0x314/0x378

Every other flow control call site in the driver already guards hardware access with either priv->globaltxfc or port->txfc. mvpp2bmswitchbuffers() is the only place that omits this check.

Add the missing priv->globaltxfc guard to both the disable and re-enable calls in mvpp2bmswitchbuffers(), consistent with the rest of the driver.

icmp: fix NULL pointer dereference in icmptagvalidation()

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

net: bridge: fix ndtbl NULL dereference when IPv6 is disabled

When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. Then, if neighsuppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, brdosuppressnd() will dereference ipv6stub->ndtbl which is NULL, passing it to neighlookup(). This causes a kernel NULL pointer dereference.

BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neighlookup+0x16/0xe0 [...] Call Trace: <IRQ> ? neighlookup+0x16/0xe0 brdosuppressnd+0x160/0x290 [bridge] brhandleframefinish+0x500/0x620 [bridge] brhandleframe+0x353/0x440 [bridge] netifreceiveskbcore.constprop.0+0x298/0x1110 netifreceiveskbonecore+0x3d/0xa0 processbacklog+0xa0/0x140 napipoll+0x2c/0x170 netrxaction+0x2c4/0x3a0 handlesoftirqs+0xd0/0x270 dosoftirq+0x3f/0x60

Fix this by replacing ISENABLED(IPV6) call with ipv6modenabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.

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

net/sched: ets: fix divide by zero in the offload path

Offloading ETS requires computing each class' WRR weight: this is done by averaging over the sums of quanta as 'qsum' and 'qpsum'. Using unsigned int, the same integer size as the individual DRR quanta, can overflow and even cause division by zero, like it happened in the following splat:

Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNEDMODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:etsoffloadchange+0x11f/0x290 [schets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: <TASK> etsqdiscchange+0x870/0xf40 [schets] qdisccreate+0x12b/0x540 tcmodifyqdisc+0x6d7/0xbd0 rtnetlinkrcvmsg+0x168/0x6b0 netlinkrcvskb+0x5c/0x110 netlinkunicast+0x1d6/0x2b0 netlinksendmsg+0x22e/0x470 syssendmsg+0x38a/0x3c0 syssendmsg+0x99/0xe0 syssendmsg+0x8a/0xf0 dosyscall64+0x111/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 </TASK> Modules linked in: schets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:etsoffloadchange+0x11f/0x290 [schets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---

Fix this using 64-bit integers for 'qsum' and 'qpsum'.

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

platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data

setnewpassword() hex dumps the entire buffer, which contains plaintext password data, including current and new passwords. Remove the hex dump to avoid leaking credentials.

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

net: phy: register phy ledtriggers during probe to avoid AB-BA deadlock

There is an AB-BA deadlock when both LEDSTRIGGERNETDEV and LEDTRIGGERPHY are enabled:

[ 1362.049207] [<8054e4b8>] ledtriggerregister+0x5c/0x1fc <-- Trying to get lock "triggerslistlock" via downwrite(&triggerslistlock); [ 1362.054536] [<80662830>] phyledtriggersregister+0xd0/0x234 [ 1362.060329] [<8065e200>] phyattachdirect+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylinkfwnodephyconnect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtkopen+0x7c/0xba0 [ 1362.075849] [<806d714c>] devopen+0x280/0x2b0 [ 1362.080384] [<806d7668>] devchangeflags+0x244/0x24c [ 1362.085598] [<806d7698>] devchangeflags+0x28/0x78 [ 1362.090528] [<807150e4>] devioctl+0x4c0/0x654 <-- Hold lock "rtnlmutex" by calling rtnllock(); [ 1362.094985] [<80694360>] sockioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sysioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscallcommon+0x34/0x58

Here LEDTRIGGERPHY is registering LED triggers during phyattach while holding RTNL and then taking triggerslistlock.

[ 1362.191101] [<806c2640>] registernetdevicenotifier+0x60/0x168 <-- Trying to get lock "rtnlmutex" via rtnllock(); [ 1362.197073] [<805504ac>] netdevtrigactivate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] ledtriggerset+0x1d4/0x360 <-- Hold lock "triggerslistlock" by downread(&triggerslistlock); [ 1362.207511] [<8054eb38>] ledtriggerwrite+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfskfbinwrite+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfsfopwriteiter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfswrite+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksyswrite+0x78/0x12c [ 1362.232164] [<80014504>] syscallcommon+0x34/0x58

Here LEDSTRIGGERNETDEV is being enabled on an LED. It first takes triggerslistlock and then RTNL. A classical AB-BA deadlock.

phyledtriggersregisters() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phyledtriggersregisters() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.

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

net: usb: kalmia: validate USB endpoints

The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.

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

RDMA/irdma: Fix kernel stack leak in irdmacreateuserah()

struct irdmacreateahresp { // 8 bytes, no padding u32 ahid; // offset 0 - SET (uresp.ahid = ah->scah.ahinfo.ahidx) u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK };

rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ahid is assigned before ibrespondudata().

The reserved members of the structure were not zeroed.

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

mptcp: pm: in-kernel: always mark signal+subflow endp as used

Syzkaller managed to find a combination of actions that was generating this warning:

msk->pm.localaddrused == 0 WARNING: net/mptcp/pmkernel.c:1071 at marksubflowendpavailable net/mptcp/pmkernel.c:1071 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pmkernel.c:1071 at mptcpnlremovesubflowandsignaladdr net/mptcp/pmkernel.c:1103 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pmkernel.c:1071 at mptcppmnldeladdrdoit+0x81d/0x8f0 net/mptcp/pmkernel.c:1210, CPU#1: syz.2.17/961 Modules linked in: CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP: 0010:marksubflowendpavailable net/mptcp/pmkernel.c:1071 [inline] RIP: 0010:mptcpnlremovesubflowandsignaladdr net/mptcp/pmkernel.c:1103 [inline] RIP: 0010:mptcppmnldeladdrdoit+0x81d/0x8f0 net/mptcp/pmkernel.c:1210 Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP: 0018:ffffc90001663880 EFLAGS: 00010293 RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: <TASK> genlfamilyrcvmsgdoit+0x117/0x180 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x16d/0x240 net/netlink/afnetlink.c:2550 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x3e9/0x4c0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x4aa/0x5b0 net/netlink/afnetlink.c:1894 socksendmsgnosec net/socket.c:727 [inline] socksendmsg+0xc9/0xf0 net/socket.c:742 syssendmsg+0x272/0x3b0 net/socket.c:2592 syssendmsg+0x2de/0x320 net/socket.c:2646 syssendmsg net/socket.c:2678 [inline] dosyssendmsg net/socket.c:2683 [inline] sesyssendmsg net/socket.c:2681 [inline] x64syssendmsg+0x110/0x1a0 net/socket.c:2681 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x143/0x440 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f66346f826d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 </TASK>

The actions that caused that seem to be:

- Set the MPTCP subflows limit to 0 - Create an MPTCP endpoint with both the 'signal' and 'subflow' flags - Create a new MPTCP connection from a different address: an ADDADDR linked to the MPTCP endpoint will be sent ('signal' flag), but no subflows is initiated ('subflow' flag) - Remove the MPTCP endpoint

---truncated---

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

perf/x86/intel/uncore: Fix die ID init and look up bugs

In snbeppci2phymapinit(), in the nrnodeids > 8 path, uncoredevicetodie() may return -1 when all CPUs associated with the UBOX device are offline.

Remove the WARNONONCE(dieid == -1) check for two reasons:

- The current code breaks out of the loop. This is incorrect because pcigetdevice() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.

- Returning -EINVAL is incorrect, since marking offline buses with dieid == -1 is expected and should not be treated as an error.

Separately, when NUMA is disabled on a NUMA-capable platform, pcibustonode() returns NUMANONODE, causing uncoredevicetodie() to return -1 for all PCI devices. As a result, sprupdatedevicelocation(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.

Fix this by using uncorepcibustodieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbeppci2phymapinit() to be added in spruncorepciinit().

Keep uncoredevicetodie() only for the nrnodeids > 8 case, where NUMA is expected to be enabled.

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