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

ipv4: validate checksumstart before completing checksum

If a packet with bad checksum metadata gets into the ipv4 stack, skbchecksumhelp can corrupt the network header and cause a bunch of mischief.

This was discovered and reported by Paulos, and has been reporoduced by others independently since.

We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum.

A more complete validation at input is forthcoming, but needs more work.

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

NFSv4.1: zero referring call lists before decoding

decodecbsequenceargs() allocates csarclists with kmallocobjs(), so each referringcalllist starts uninitialized. decoderclist() assigns rclrefcalls only when rclnrefcalls is nonzero. A valid list with zero referring calls therefore leaves the pointer uninitialized, and nfs4callbacksequence() later passes stale slab contents to kfree().

Allocate csarclists with kzallocobjs() so every rclrefcalls member is NULL from the beginning, including valid empty referring call lists.

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

smb: client: fix OOB read/write from unvalidated DataOffset in coalescet2()

coalescet2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds:

dataareaoftgt = (char )&pSMBt->hdr.Protocol + getunalignedle16(&pSMBt->t2rsp.DataOffset); dataareaofsrc = (char )&pSMBs->hdr.Protocol + getunalignedle16(&pSMBs->t2rsp.DataOffset); dataareaoftgt += totalintgt; ... memcpy(dataareaoftgt, dataareaofsrc, totalinsrc);

A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts.

The "validate target area" comment present since the function was first written in 2005 was a placeholder that was never implemented.

Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified.

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

idpf: bound interrupt-vector register fill to the allocated array

idpfgetregintrvecs() fills the caller-allocated regvals[] array from the VIRTCHNL2OPALLOCVECTORS reply in adapter->reqvecchunks, bounding its inner loop only by the per-chunk numvectors. The array is sized separately: idpfintrreginit() allocates kzallocobjs(struct idpfvecregs, totalvecs) from caps.numallocatedvectors and only checks the returned count after the fill. The sum of per-chunk numvectors is never reconciled against totalvecs, so a reply with a small numallocatedvectors but chunks summing higher writes past the end of regvals[].

Impact: a control plane (a PF or hypervisor device model) that returns a VIRTCHNL2OPALLOCVECTORS reply whose per-chunk numvectors sum exceeds numallocatedvectors writes struct idpfvecregs entries past the end of the regvals kmalloc allocation (KASAN slab-out-of-bounds write).

Bound the fill loop to the array capacity passed in by the callers, mirroring the sibling idpfvportgetqreg(). The existing numregs < numvecs check then rejects an undersized reply without the out-of-bounds write happening first.

btrfs: lzo: reject inline extents without valid headers

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

fs/ntfs3: call ntfsbadinode() when failing to rename

It is safe to call ntfsbadinode on live inodes since: commit 519b078998ce ("fs/ntfs3: Exclude call makebadinode for live nodes.")

The WARNON was added when it wasn't safe by: commit d99208b91933 ("fs/ntfs3: cancle set bad inode after removing name fails")

Replace the WARNON with a call to ntfsbadinode() to prevent further operations on the inconsistent inode.

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

net/liquidio: drop cached VF pcidev LUT

The PF SR-IOV enable path caches VF pcidev pointers in dpiringtovfpcidevlut[] by iterating with pcigetdevice(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEONVFFLRREQUEST.

Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from qno, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcieflr() and drop the reference with pcidevput(). Remove the unused VF lookup table initialization and cleanup.

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

netfs: Fix missing barriers when accessing stream->subrequests locklessly

The list of subrequests attached to stream->subrequests is accessed without locks by netfscollectreadresults() and netfscollectwriteresults(), and then they access subreq->flags without taking a barrier after getting the subreq pointer from the list. Relatedly, the functions that build the list don't use any sort of write barrier when constructing the list to make sure that the NETFSSREQINPROGRESS flag is perceived to be set first if no lock is taken.

Fix this by:

(1) Add a new listaddtailrelease() function that uses a release barrier to set the pointer to the new member of the list.

(2) Add a new listfirstentryornullacquire() function that uses an acquire barrier to read the pointer to the first member in a list (or return NULL).

(3) Use listaddtailrelease() when adding a subreq to ->subrequests.

(4) Use listfirstentryornullacquire() when initially accessing the front of the list (when an item is removed, the pointer to the new front iterm is obtained under the same lock).

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

scsi: qla2xxx: Completely fix fcport double free

In qla24xxelsdcmdiocb() sp->free is set to qla2x00elsdcmdspfree(). When an error happens, this function is called by qla2x00sprelease(), when krefput() releases the first and the last reference.

qla2x00elsdcmdspfree() frees fcport by calling qla2x00freefcport(). Doing it one more time after krefput() is a bad idea.

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

net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path

cppi5hdescgetpsdata() returns a pointer into the CPPI descriptor. In both emacrxpacket() and emacrxpacketzc(), the descriptor is freed via k3cppidescpoolfree() before the psdata pointer is used by emacrxtimestamp(), which dereferences psdata[0] and psdata[1]. This constitutes a use-after-free on every received packet that goes through the timestamp path.

Defer the descriptor free until after all accesses through the psdata pointer are complete. For emacrxpacket(), move the free into the requeue label so both early-exit and success paths free the descriptor after all accesses are done. For emacrxpacketzc(), move the free to the end of the loop body after emacdispatchskbzc() (which calls emacrxtimestamp()) has returned.

bpf: Scrub packet on bpfredirectpeer

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

nfsd: clear aclaccess/acldefault after releasing them

If getting acldefault fails, aclaccess and acldefault will be released simultaneously. However, aclaccess will still retain a pointer pointing to the released posixacl, which will trigger a WARNING in nfs3svcreleasegetacl like this:

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcountwarnsaturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarnsaturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcountwarnsaturate+0xb5/0x170 ? warn+0xa5/0x140 ? refcountwarnsaturate+0xb5/0x170 ? reportbug+0x1b1/0x1e0 ? handlebug+0x53/0xa0 ? excinvalidop+0x17/0x40 ? asmexcinvalidop+0x1a/0x20 ? ticknohztickstopped+0x1e/0x40 ? refcountwarnsaturate+0xb5/0x170 ? refcountwarnsaturate+0xb5/0x170 nfs3svcreleasegetacl+0xc9/0xe0 svcprocesscommon+0x5db/0xb60 ? pfxsvcprocesscommon+0x10/0x10 ? rcureadunlock+0x69/0xa0 ? pfxnfsddispatch+0x10/0x10 ? svcxprtreceived+0xa1/0x120 ? xdrinitdecode+0x11d/0x190 svcprocess+0x2a7/0x330 svchandlexprt+0x69d/0x940 svcrecv+0x180/0x2d0 nfsd+0x168/0x200 ? pfxnfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: paniconwarn set ...

Clear aclaccess/acldefault after posixaclrelease is called to prevent UAF from being triggered.

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

mptcp: consolidate suboption status

MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info.

Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption.

The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized:

BUG: KMSAN: uninit-value in mptcpexpandseq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcpexpandseq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ackupdatemsk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcpincomingoptions+0x2036/0x3d30 net/mptcp/options.c:1209 mptcpexpandseq net/mptcp/options.c:1030 [inline] mptcpexpandseq net/mptcp/protocol.h:864 [inline] ackupdatemsk net/mptcp/options.c:1060 [inline] mptcpincomingoptions+0x2036/0x3d30 net/mptcp/options.c:1209 tcpdataqueue+0xb4/0x7be0 net/ipv4/tcpinput.c:5233 tcprcvestablished+0x1061/0x2510 net/ipv4/tcpinput.c:6264 tcpv4dorcv+0x7f3/0x11a0 net/ipv4/tcpipv4.c:1916 tcpv4rcv+0x51df/0x5750 net/ipv4/tcpipv4.c:2351 ipprotocoldeliverrcu+0x2a3/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:314 [inline] iplocaldeliver+0x21f/0x490 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:460 [inline] iprcvfinish+0x4a2/0x520 net/ipv4/ipinput.c:447 NFHOOK include/linux/netfilter.h:314 [inline] iprcv+0xcd/0x380 net/ipv4/ipinput.c:567 netifreceiveskbonecore net/core/dev.c:5704 [inline] netifreceiveskb+0x319/0xa00 net/core/dev.c:5817 processbacklog+0x4ad/0xa50 net/core/dev.c:6149 napipoll+0xe7/0x980 net/core/dev.c:6902 napipoll net/core/dev.c:6971 [inline] netrxaction+0xa5a/0x19b0 net/core/dev.c:7093 handlesoftirqs+0x1a0/0x7c0 kernel/softirq.c:561 dosoftirq+0x14/0x1a kernel/softirq.c:595 dosoftirq+0x9a/0x100 kernel/softirq.c:462 localbhenableip+0x9f/0xb0 kernel/softirq.c:389 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:919 [inline] devqueuexmit+0x2758/0x57d0 net/core/dev.c:4493 devqueuexmit include/linux/netdevice.h:3168 [inline] neighhhoutput include/net/neighbour.h:523 [inline] neighoutput include/net/neighbour.h:537 [inline] ipfinishoutput2+0x187c/0x1b70 net/ipv4/ipoutput.c:236 ipfinishoutput+0x287/0x810 ipfinishoutput+0x4b/0x600 net/ipv4/ipoutput.c:324 NFHOOKCOND include/linux/netfilter.h:303 [inline] ipoutput+0x15f/0x3f0 net/ipv4/ipoutput.c:434 dstoutput include/net/dst.h:450 [inline] iplocalout net/ipv4/ipoutput.c:130 [inline] ipqueuexmit+0x1f2a/0x20d0 net/ipv4/ipoutput.c:536 ipqueuexmit+0x60/0x80 net/ipv4/ipoutput.c:550 tcptransmitskb+0x3cea/0x4900 net/ipv4/tcpoutput.c:1468 tcptransmitskb net/ipv4/tcpoutput.c:1486 [inline] tcpwritexmit+0x3b90/0x9070 net/ipv4/tcpoutput.c:2829 tcppushpendingframes+0xc4/0x380 net/ipv4/tcpoutput.c:3012 tcpsendfin+0x9f6/0xf50 net/ipv4/tcpoutput.c:3618 tcpclose+0x140c/0x1550 net/ipv4/tcp.c:3130 mptcpclosessk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcpclosessk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcppmnlrmaddrorsubflow+0x635/0xd10 net/mptcp/pmnetlink.c:889 mptcppmnlrmsubflowreceived net/mptcp/pmnetlink.c:924 [inline] mptcppmflushaddrsandsubflows net/mptcp/pmnetlink.c:1688 [inline] mptcpnlflushaddrslist net/mptcp/pmnetlink.c:1709 [inline] mptcppmnlflushaddrsdoit+0xe10/0x1630 net/mptcp/pmnetlink.c:1750 genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] ---truncated---

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

nfsd: fix nfs4openowner leak when concurrent nfsd4open occur

The action force umount(umount -f) will attempt to kill all rpctask even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpctask to nfs server.

NFS CLIENT thread1 thread2 open("file") ... nfs4doopen nfs4doopen nfs4openandgetstate nfs4procopen nfs4runopentask / rpctask1 / rpcruntask rpcwaitforcompletiontask

umount -f nfsumountbegin rpckillalltasks rpcsignaltask rpctask1 been wakeup and return -512 nfs4doopen // while loop ... nfs4runopentask / rpctask2 / rpcruntask rpcwaitforcompletiontask

While processing an open request, nfsd will first attempt to find or allocate an nfs4openowner. If it finds an nfs4openowner that is not marked as NFS4OOCONFIRMED, this nfs4openowner will released. Since two rpctask can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.

NFS SERVER nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads

nfsd4open nfsd4processopen1 findorallocopenstateowner // alloc oo1, stateid1 nfsd4open nfsd4processopen1 findorallocopenstateowner // find oo1, without NFS4OOCONFIRMED releaseopenowner unhashopenownerlocked listdelinit(&oo->ooperclient) // cannot find this oo // from client, LEAK!!! allocstateowner // alloc oo2

nfsd4processopen2 initopenstateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4getvfsfile // alloc nfsdfile1 and nfsdfilemark1 // all LEAK!!!

nfsd4processopen2 ...

writethreads ... nfsddestroyserv nfsdshutdownnet nfs4stateshutdownnet nfs4statedestroynet destroyclient destroyclient // won't find oo1!!! nfsdshutdowngeneric nfsdfilecacheshutdown kmemcachedestroy for nfsdfileslab and nfsdfilemarkslab // bark since nfsdfile1 // and nfsdfilemark1 // still alive

======================================================================= BUG nfsdfile (Not tainted): Objects remaining in nfsdfile on kmemcacheshutdown() -----------------------------------------------------------------------

Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated---

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

net: stmmac: fix TSO DMA API usage causing oops

Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of txskbuffdma[]'s members to be later in stmmactsoxmit().

The buf (dma cookie) and len stored in this structure are passed to dmaunmapsingle() by stmmactxclean(). The DMA API requires that the dma cookie passed to dmaunmapsingle() is the same as the value returned from dmamapsingle(). However, by moving the assignment later, this is not the case when priv->dmacap.addr64 > 32 as "des" is offset by protohdrlen.

This causes problems such as:

dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed

and with DMAAPIDEBUG enabled:

DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]

Fix this by maintaining "des" as the original DMA cookie, and use tsodes to pass the offset DMA cookie to stmmactsoallocator().

Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/

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

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

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

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

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

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

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

netfilter: nfnetlinkosf: fix out-of-bounds read on option matching

In nfosfmatch(), the nfosfhdrctx structure is initialized once and passed by reference to nfosfmatchone() for each fingerprint checked. During TCP option parsing, nfosfmatchone() advances the shared ctx->optp pointer.

If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NFOSFLOGLEVELALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nfosfmatchone() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches.

Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nfosfmatchone() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset.

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

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

net: qrtr: fix refcount saturation and potential UAF in qrtrportremove

In qrtrportremove(), the socket reference count is decremented via sockput() before the port is removed from the qrtrports XArray and before the RCU grace period elapses.

This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtrresetports() or qrtrportlookup()) can obtain a pointer to the socket from the XArray, and attempt to call sockhold() on a socket whose reference count has already dropped to zero.

This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free:

refcountt: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcountwarnsaturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drmshmemhelper ... Call Trace: <TASK> qrtrresetports net/qrtr/afqrtr.c:768 [inline] [qrtr] qrtrbind.isra.0+0x48b/0x570 net/qrtr/afqrtr.c:805 [qrtr] qrtrbind+0x17d/0x210 net/qrtr/afqrtr.c:901 [qrtr] kernelbind+0xe4/0x120 net/socket.c:3592 qrtrnsinit+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtrprotoinit+0x3b/0xff0 net/qrtr/afqrtr.c:169 [qrtr] dooneinitcall+0xf5/0x5e0 init/main.c:1283 ... </TASK>

Fix this by deferring the reference count decrement until after the xaerase() and the synchronizercu() complete.

(Note: The v1 of this patch incorrectly replaced sockput() with sockput(). As Simon Horman pointed out, the callers of qrtrportremove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the sockput() is kept, but only repositioned to close the RCU race.)

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

smb: client: validate dacloffset before building DACL pointers

parsesecdesc(), buildsecdesc(), and the chown path in idmodetocifsacl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor.

On 32-bit builds a malicious server can return dacloffset near U32MAX, wrap the derived DACL pointer below endofacl, and then slip past the later pointer-based bounds checks. buildsecdesc() and idmodetocifsacl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths.

Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.

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

smb/client: fix out-of-bounds read in symlinkdata()

Since smb2checkmessage() returns success without length validation for the symlink error response, in symlinkdata() it is possible for iov->iovlen to be smaller than sizeof(struct smb2errrsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlinkdata() will cause an out-of-bounds read.

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

mptcp: pm: ADDADDR rtx: fix potential data-race

This mptcppmaddtimer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bhlocksock().

If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.

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

ipv6: rpl: reserve maclen headroom when recompressed SRH grows

ipv6rplsrhrcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).

pskbexpandhead() was gated on segmentsleft == 0, so on earlier segments the push consumed unchecked headroom. Once skbpush() leaves fewer than skb->maclen bytes in front of data, skbmacheaderrebuild()'s call to:

skbsetmacheader(skb, -skb->maclen);

will store (data - head) - maclen into the u16 macheader field, which wraps to ~65530, and the following memmove() writes maclen bytes ~64KiB past skb->head.

A single AFINET6/SOCKRAW/IPV6HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6rthdrrcv.

Fix this by expanding the head whenever the remaining room is less than the push size plus maclen, and request that much extra so the rebuilt MAC header fits afterwards.

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

crypto: pcrypt - Fix handling of MAYBACKLOG requests

MAYBACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.

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

btrfs: tracepoints: get correct superblock from dentry in event btrfssyncfile()

If overlay is used on top of btrfs, dentry->dsb translates to overlay's super block and fsid assignment will lead to a crash.

Use fileinode(file)->isb to always get btrfssb.