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

tcp: drop secpath at the same time as we currently drop dst

Xiumei reported hitting the WARN in xfrm6tunnelnetexit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns

The xfrmstate found on spibyaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrmstate), which is still attached to an skb. This skb is not leaked, it ends up on skreceivequeue and then gets defer-free'd by skbattemptdeferfree.

The problem happens when we defer freeing an skb (push it on one CPU's deferlist), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrmstate that we don't expect at this point.

We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcpfilter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.

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

NFSD: fix hang in nfsd4shutdowncallback

If nfs4client is in courtesy state then there is no point to send the callback. This causes nfsd4shutdowncallback to hang since clcbinflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped.

This patch modifies nfsd4runcbwork to skip the RPC call if nfs4client is in courtesy state.

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

block: fix uaf for flush rq while iterating tags

blkmqclearflushrqmapping() is not called during scsi probe, by checking blkqueueinitdone(). However, QUEUEFLAGINITDONE is cleared in delgendisk by commit aec89dc5d421 ("block: keep qusagecounter in atomic mode after delgendisk"), hence for disk like scsi, following blkmqdestroyqueue() will not clear flush rq from tags->rqs[] as well, cause following uaf that is found by our syzkaller for v6.6:

================================================================== BUG: KASAN: slab-use-after-free in blkmqfindandgetreq+0x16e/0x1a0 block/blk-mq-tag.c:261 Read of size 4 at addr ffff88811c969c20 by task kworker/1:2H/224909

CPU: 1 PID: 224909 Comm: kworker/1:2H Not tainted 6.6.0-ga836a5060850 #32 Workqueue: kblockd blkmqtimeoutwork Call Trace:

dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x91/0xf0 lib/dumpstack.c:106 printaddressdescription.constprop.0+0x66/0x300 mm/kasan/report.c:364 printreport+0x3e/0x70 mm/kasan/report.c:475 kasanreport+0xb8/0xf0 mm/kasan/report.c:588 blkmqfindandgetreq+0x16e/0x1a0 block/blk-mq-tag.c:261 btiter block/blk-mq-tag.c:288 [inline] sbitmapforeachset include/linux/sbitmap.h:295 [inline] sbitmapforeachset include/linux/sbitmap.h:316 [inline] btforeach+0x455/0x790 block/blk-mq-tag.c:325 blkmqqueuetagbusyiter+0x320/0x740 block/blk-mq-tag.c:534 blkmqtimeoutwork+0x1a3/0x7b0 block/blk-mq.c:1673 processonework+0x7c4/0x1450 kernel/workqueue.c:2631 processscheduledworks kernel/workqueue.c:2704 [inline] workerthread+0x804/0xe40 kernel/workqueue.c:2785 kthread+0x346/0x450 kernel/kthread.c:388 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1b/0x30 arch/x86/entry/entry64.S:293

Allocated by task 942: kasansavestack+0x22/0x50 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasankmalloc mm/kasan/common.c:374 [inline] kasankmalloc mm/kasan/common.c:383 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:380 kasankmalloc include/linux/kasan.h:198 [inline] dokmallocnode mm/slabcommon.c:1007 [inline] kmallocnode+0x69/0x170 mm/slabcommon.c:1014 kmallocnode include/linux/slab.h:620 [inline] kzallocnode include/linux/slab.h:732 [inline] blkallocflushqueue+0x144/0x2f0 block/blk-flush.c:499 blkmqallochctx+0x601/0x940 block/blk-mq.c:3788 blkmqallocandinithctx+0x27f/0x330 block/blk-mq.c:4261 blkmqreallochwctxs+0x488/0x5e0 block/blk-mq.c:4294 blkmqinitallocatedqueue+0x188/0x860 block/blk-mq.c:4350 blkmqinitqueuedata block/blk-mq.c:4166 [inline] blkmqinitqueue+0x8d/0x100 block/blk-mq.c:4176 scsiallocsdev+0x843/0xd50 drivers/scsi/scsiscan.c:335 scsiprobeandaddlun+0x77c/0xde0 drivers/scsi/scsiscan.c:1189 scsiscantarget+0x1fc/0x5a0 drivers/scsi/scsiscan.c:1727 scsiscanchannel drivers/scsi/scsiscan.c:1815 [inline] scsiscanchannel+0x14b/0x1e0 drivers/scsi/scsiscan.c:1791 scsiscanhostselected+0x2fe/0x400 drivers/scsi/scsiscan.c:1844 scsiscan+0x3a0/0x3f0 drivers/scsi/scsisysfs.c:151 storescan+0x2a/0x60 drivers/scsi/scsisysfs.c:191 devattrstore+0x5c/0x90 drivers/base/core.c:2388 sysfskfwrite+0x11c/0x170 fs/sysfs/file.c:136 kernfsfopwriteiter+0x3fc/0x610 fs/kernfs/file.c:338 callwriteiter include/linux/fs.h:2083 [inline] newsyncwrite+0x1b4/0x2d0 fs/readwrite.c:493 vfswrite+0x76c/0xb00 fs/readwrite.c:586 ksyswrite+0x127/0x250 fs/readwrite.c:639 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x70/0x120 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x78/0xe2

Freed by task 244687: kasansavestack+0x22/0x50 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasansavefreeinfo+0x2b/0x50 mm/kasan/generic.c:522 kasanslabfree mm/kasan/common.c:236 [inline] kasanslabfree+0x12a/0x1b0 mm/kasan/common.c:244 kasanslabfree include/linux/kasan.h:164 [in ---truncated---

bpf: Fix overloading of MEMUNINIT's meaning

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

riscv: Fix register corruption from uninitialized cregs on error

compatriscvgprset() calls cregstoregs() unconditionally, even when userregsetcopyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's ptregs, corrupting its register state and potentially leaking kernel stack contents.

compatrestoresigcontext() has the same issue: it calls cregstoregs() even when copyfromuser() fails, leading to the same corruption of the signal-returning task's register state on error.

Only call cregstoregs() when the user copy succeeds.

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

usb: gadget: udc: Fix use-after-free in gadgetmatchdriver

The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usbdelgadget() frees the udc memory (e.g., via mode-switch work) while gadgetmatchdriver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed:

[39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : pistrcmp+0x20/0x140 [39430.911441][ T1171] lr : gadgetmatchdriver+0x34/0x60 ... [39430.911890][ T1171] usbgadgetregisterdriverowner+0x50/0xf8 [39430.911910][ T1171] gadgetdevdescUDCstore+0xf4/0x140 [39430.931308][ T1171] configfswriteiter+0xec/0x134

[39430.957058][ T1171] Workqueue: eventsfreezable dwc3setmode [39430.957287][ T1171] dwc3gadgetexit+0x34/0x8c [39430.957304][ T1171] dwc3setmode+0xc0/0x664

Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usbgadgetrelease() routine to the core. When the gadget is added, usbaddgadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usbgadgetrelease() drops the reference to the udc and then calls the gadget's release routine.

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

mptcp: make fallback action and fallback decision atomic

Syzkaller reported the following splat:

WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 checkfullyestablished net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:checkfullyestablished net/mptcp/options.c:982 [inline] RIP: 0010:mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: <IRQ> tcpreset+0x26f/0x2b0 net/ipv4/tcpinput.c:4432 tcpvalidateincoming+0x1057/0x1b60 net/ipv4/tcpinput.c:5975 tcprcvestablished+0x5b5/0x21f0 net/ipv4/tcpinput.c:6166 tcpv4dorcv+0x5dc/0xa70 net/ipv4/tcpipv4.c:1925 tcpv4rcv+0x3473/0x44a0 net/ipv4/tcpipv4.c:2363 ipprotocoldeliverrcu+0xba/0x480 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2f1/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iplocaldeliver+0x1be/0x560 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:469 [inline] iprcvfinish net/ipv4/ipinput.c:447 [inline] NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iprcv+0x514/0x810 net/ipv4/ipinput.c:567 netifreceiveskbonecore+0x197/0x1e0 net/core/dev.c:5975 netifreceiveskb+0x1f/0x120 net/core/dev.c:6088 processbacklog+0x301/0x1360 net/core/dev.c:6440 napipoll.constprop.0+0xba/0x550 net/core/dev.c:7453 napipoll net/core/dev.c:7517 [inline] netrxaction+0xb44/0x1010 net/core/dev.c:7644 handlesoftirqs+0x1d0/0x770 kernel/softirq.c:579 dosoftirq+0x3f/0x90 kernel/softirq.c:480 </IRQ> <TASK> localbhenableip+0xed/0x110 kernel/softirq.c:407 localbhenable include/linux/bottomhalf.h:33 [inline] inetcsklistenstop+0x2c5/0x1070 net/ipv4/inetconnectionsock.c:1524 mptcpchecklistenstop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcpchecklistenstop net/mptcp/mib.h:118 [inline] mptcpclose+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcpclose+0x2f/0x140 net/mptcp/protocol.c:3066 inetrelease+0xed/0x200 net/ipv4/afinet.c:435 inet6release+0x4f/0x70 net/ipv6/afinet6.c:487 sockrelease+0xb3/0x270 net/socket.c:649 sockclose+0x1c/0x30 net/socket.c:1439 fput+0x402/0xb70 fs/filetable.c:465 taskworkrun+0x150/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xd4 ---truncated---

A use-after-free flaw was found in nftables cross-table in the net/netfilter/nftablesapi.c function in the Linux kernel. This flaw allows a local, privileged attacker to cause a use-after-free problem at the time of table deletion, possibly leading to local privilege escalation.

drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11

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

drm/amdgpu: Fix potential out-of-bounds access in 'amdgpudiscoveryregbaseinit()'

The issue arises when the array 'adev->vcn.vcnconfig' is accessed before checking if the index 'adev->vcn.numvcninst' is within the bounds of the array.

The fix involves moving the bounds check before the array access. This ensures that 'adev->vcn.numvcninst' is within the bounds of the array before it is used as an index.

Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpudiscovery.c:1289 amdgpudiscoveryregbaseinit() error: testing array offset 'adev->vcn.numvcninst' after use.

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

drm/i915/vma: Fix UAF on destroy against retire race

Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle.

[161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915active hint: i915vmaactive+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debugprintobject+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CIDRM13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered intelwakerefputwork [i915] [161.360592] RIP: 0010:debugprintobject+0x80/0xb0 ... [161.361347] debugobjectfree+0xeb/0x110 [161.361362] i915activefini+0x14/0x130 [i915] [161.361866] releasereferences+0xfe/0x1f0 [i915] [161.362543] i915vmaparked+0x1db/0x380 [i915] [161.363129] gtpark+0x121/0x230 [i915] [161.363515] intelwakerefputlast+0x1f/0x70 [i915]

That has been tracked down to be happening when another thread is deactivating the VMA inside activeretire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool.

We could prevent from that race by serializing i915activefini() with activeretire() via ref->treelock, but that wouldn't stop the VMA from being used, e.g. from i915vmaretire() called at the end of activeretire(), after that VMA has been already freed by a concurrent i915vmadestroy() on return from the i915activefini(). Then, we should rather fix the issue at the VMA level, not in i915active.

Since i915vmaparked() is called from gtpark() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for activeretire() to complete before that wakeref is released and the GT parked.

I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915activefini() from a dropped i915vmarelease(), called on last put of the removed VMA kref, to i915vmaparked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation").

A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intelcontext for a GT associated with its VM, and indirectly on that intelcontext's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation.

Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since i915vmaretire() may be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed.

v7: Add inline comments with justifications for: - using untracked variants of intelgtpmget/put() (Nirmoy), - using async variant of put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since i915vmaactive/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915vma is not safe, and there is no other good place for that. Use untracked variants of intelgtpmget/putasync(). v5: Replace "tile" with "GT" across commit description (Rodrigo), - ---truncated---

A flaw was found in the Linux kernel's udmabuf device driver, within a fault handler. This issue occurs due to the lack of proper validation of user-supplied data, which can result in memory access past the end of an array. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel.

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

x86/tdx: Fix "in-kernel MMIO" check

TDX only supports kernel-initiated MMIO operations. The handlemmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not.

However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does getuser() or putuser() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO.

Ensure that the target MMIO address is within the kernel before decoding instruction.

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

mptcp: allow subflow rcv wnd to shrink

In MPTCP connection, the window field in the TCP header refers to the MPTCP-level rcvnxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time.

At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog).

As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving.

Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.

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

mtd: spi-nor: debugfs: fix out-of-bounds read in spinorparamsshow()

Sashiko noticed an out-of-bounds read [1].

In spinorparamsshow(), the snorfnames array is passed to spinorprintflags() using sizeof(snorfnames).

Since snorfnames is an array of pointers, sizeof() returns the total number of bytes occupied by the pointers (elementcount sizeof(void )) rather than the element count itself. On 64-bit systems, this makes the passed length 8x larger than intended.

Inside spinorprintflags(), the 'nameslen' argument is used to bounds-check the 'names' array access. An out-of-bounds read occurs if a flag bit is set that exceeds the array's actual element count but is within the inflated byte-size count.

Correct this by using ARRAYSIZE() to pass the actual number of string pointers in the array.

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

netfilter: nfconncount: increase the connection clean up limit to 64

After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly.

In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs.

This has been tested using a HTTP server and several performance tools while having nftconnlimit/xtconnlimit or OVS limit configured.

Output of slowhttptest + OVS limit at 52000 connections:

slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES

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

net: wwan: t7xx: validate portcount against message length in t7xxportenummsghandler

t7xxportenummsghandler() uses the modem-supplied portcount field as a loop bound over portmsg->data[] without checking that the message buffer contains sufficient data. A modem sending portcount=65535 in a 12-byte buffer triggers a slab-out-of-bounds read of up to 262140 bytes.

Add a sizeof(portmsg) check before accessing the port message header fields to guard against undersized messages.

Add a structsize() check after extracting portcount and before the loop.

In t7xxparsehostrtdata(), guard the rtfeature header read with a remaining-buffer check before accessing datalen, validate featdatalen against the actual remaining buffer to prevent OOB reads and signed integer overflow on offset.

Pass msglen from both call sites: skb->len at the DPMAIF path after skbpull(), and the validated featdatalen at the handshake path.

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

iouring/kbuf: check if target buffer list is still legacy on recycle

There's a gap between when the buffer was grabbed and when it potentially gets recycled, where if the list is empty, someone could've upgraded it to a ring provided type. This can happen if the request is forced via io-wq. The legacy recycling is missing checking if the bufferlist still exists, and if it's of the correct type. Add those checks.

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

vhost: move vdpa group bound check to vhostvdpa

Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them.

While we're at it, fix a bug in vdpasim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.

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

smb: client: prevent races in ->queryinterfaces()

It was possible for two query interface works to be concurrently trying to update the interfaces.

Prevent this by checking and updating ifacelastupdate under ifacelock.

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

LoongArch: Make cpumaskofnode() robust against NUMANONODE

The arch definition of cpumaskofnode() cannot handle NUMANONODE - which is a valid index - so add a check for this.

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

net: wwan: t7xx: fix potential skb->frags overflow in RX path

When receiving data in the DPMAIF RX path, the t7xxdpmaifsetfragtoskb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAXSKBFRAGS. This could lead to a buffer overflow in skbshinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior.

This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76: fix array overflow on receiving too many fragments for a packet").

The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects.

Fix this by adding a bounds check before calling skbaddrxfrag() to ensure nrfrags does not exceed MAXSKBFRAGS.

The check must be performed before unmapping to avoid a page leak and double DMA unmap during device teardown.

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

netfilter: nfconncount: update lastgc only when GC has been performed

Currently lastgc is being updated everytime a new connection is tracked, that means that it is updated even if a GC wasn't performed. With a sufficiently high packet rate, it is possible to always bypass the GC, causing the list to grow infinitely.

Update the lastgc value only when a GC has been actually performed.

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

iouring: fix ioreqprepasync with provided buffers

ioreqprepasync() can import provided buffers, commit the ring state by giving up on that before, it'll be reimported later if needed.

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

ipmi:msghandler: Fix potential memory corruption in ipmicreateuser()

The "intf" list iterator is an invalid pointer if the correct "intf->intfnum" is not found. Calling atomicdec(&intf->nrusers) on and invalid pointer will lead to memory corruption.

We don't really need to call atomicdec() if we haven't called atomicaddreturn() so update the if (intf->inshutdown) path as well.

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

NFSv4/pNFS: Fix a race to wake on NFSLAYOUTDRAIN

We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFSLAYOUTDRAIN bit in pnfsupdatelayout(), however the pnfslayouthdr's plhoutstanding count was zero.

It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier.

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

can: bcm: add missing rcu read protection for procfs content

When the procfs content is generated for a bcmop which is in the process to be removed the procfs output might show unreliable data (UAF).

As the removal of bcmop's is already implemented with rcu handling this patch adds the missing rcureadlock() and makes sure the list entries are properly removed under rcu protection.

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

LoongArch: Increase ARCHDMAMINALIGN up to 16

ARCHDMAMINALIGN is 1 by default, but some LoongArch-specific devices (such as APBDMA) require 16 bytes alignment. When the data buffer length is too small, the hardware may make an error writing cacheline. Thus, it is dangerous to allocate a small memory buffer for DMA. It's always safe to define ARCHDMAMINALIGN as L1CACHEBYTES but unnecessary (kmalloc() need small memory objects). Therefore, just increase it to 16.

eth: bnxt: fix truesize for mb-xdp-pass case

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

eth: bnxt: do not update checksum in bnxtxdpbuildskb()

The bnxtrxpkt() updates ipsummed value at the end if checksum offload is enabled. When the XDP-MB program is attached and it returns XDPPASS, the bnxtxdpbuildskb() is called to update skbsharedinfo. The main purpose of bnxtxdpbuildskb() is to update skbsharedinfo, but it updates ipsummed value too if checksum offload is enabled. This is actually duplicate work.

When the bnxtrxpkt() updates ipsummed value, it checks if ipsummed is CHECKSUMNONE or not. It means that ipsummed should be CHECKSUMNONE at this moment. But ipsummed may already be updated to CHECKSUMUNNECESSARY in the XDP-MB-PASS path. So the by skbchecksumnoneassert() WARNS about it.

This is duplicate work and updating ipsummed in the bnxtxdpbuildskb() is not needed.

Splat looks like: WARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxtrxpkt+0x479b/0x7610 [bnxten] Modules linked in: bnxtre bnxten rdmaucm rdmacm iwcm ibcm ibuverbs veth xtnat xttcpudp xtconntrack nftchainnat xtMASQUERADE nf] CPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G W 6.14.0-rc4+ #27 Tainted: [W]=WARN Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bnxtrxpkt+0x479b/0x7610 [bnxten] Code: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b f RSP: 0018:ffff88881ba09928 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000 RDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8 RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070 R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080 R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000 FS: 00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <IRQ> ? warn+0xcd/0x2f0 ? bnxtrxpkt+0x479b/0x7610 ? reportbug+0x326/0x3c0 ? handlebug+0x53/0xa0 ? excinvalidop+0x14/0x50 ? asmexcinvalidop+0x16/0x20 ? bnxtrxpkt+0x479b/0x7610 ? bnxtrxpkt+0x3e41/0x7610 ? pfxbnxtrxpkt+0x10/0x10 ? napicompletedone+0x2cf/0x7d0 bnxtpollwork+0x4e8/0x1220 ? pfxbnxtpollwork+0x10/0x10 ? pfxmarklock.part.0+0x10/0x10 bnxtpollp5+0x36a/0xfa0 ? pfxbnxtpollp5+0x10/0x10 napipoll.constprop.0+0xa0/0x440 netrxaction+0x899/0xd00 ...

Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be able to reproduce this issue.