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

netfs: Fix zeropoint update where isize > remoteisize

Fix the update of the zero point[] by netfsreleasefolio() when there is uncommitted data in the pagecache beyond the folio being released but the on-server EOF is in this folio (ie. isize > remoteisize). The update needs to limit zeropoint to remoteisize, not isize as isize is a local phenomenon reflecting updates made locally to the pagecache, not stuff written to the server. remoteisize tracks the server's isize.

[] The zero point is the file position from which we can assume that the server will just return zeros, so we can avoid generating reads.

Note that netfsinvalidatefolio() probably doesn't need fixing as zeropoint should be updated by setattr after truncation or fallocate.

Found with:

fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops

using the following as junk.fsxops:

truncate 0x0 0x1bbae 0x82864 write 0x3ef2e 0xf9c8 0x1bbae write 0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copyrange 0x5d3d 0x10329 0x54fac 0x7495f write 0x64710 0x1c2b 0x7495f mapread 0x64000 0x1000 0x7495f

on cifs with the default cache option.

It shows read-gaps on folio 0x64 failing with a short read (ie. it hits EOF) if the FMODEREAD check is commented out in netfsperformwrite():

if (//(file->fmode & FMODEREAD) || netfsiscacheenabled(ctx)) {

and no fscache. This was initially found with the generic/522 xfstest.

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

wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiexcmd80211scanext()

Replace one-element array with a flexible-array member in struct hostcmdds80211scanext.

With this, fix the following warning:

elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "extscan->tlvbuffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiexcmd80211scanext+0x83/0x90 [mwifiex]

ext4: dax: fix overflowing extents beyond inode size when partially writing

ext4: fix access to uninitialised lock in fc replay path

ext4: fix idatasem unlock order in ext4indmigrate()

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

net: stmmac: Fix zero-division error when disabling tc cbs

The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider when offload is disabled") allows the "porttransmitratekbps" to be set to a value of 0, which is then passed to the "divs64" function when tc-cbs is disabled. This leads to a zero-division error.

When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.

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

net: dsa: improve shutdown sequence

Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there.

The first problem is that lan9303 is unique among DSA drivers in that it calls devgetdrvdata() at "arbitrary runtime" (not probe, not shutdown, not remove):

phystatemachine() -> ... -> dsauserphyread() -> ds->ops->phyread() -> lan9303phyread() -> chip->ops->phyread() -> lan9303mdiophyread() -> devgetdrvdata()

But we never stop the phystatemachine(), so it may continue to run after dsaswitchshutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD.

The second problem is that the way in which we set dp->conduit->dsaptr = NULL; is concurrent with receive packet processing. dsaswitchrcv() checks once whether dev->dsaptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsaptr is dereferenced again and again without NULL checks: dsaconduitfinduser() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid.

Both problems have the common aspect that closing the conduit interface solves them.

In the first case, devclose(conduit) triggers the NETDEVGOINGDOWN event in dsausernetdeviceevent() which closes user ports as well. dsaportdisablert() calls phylinkstop(), which synchronously stops the phylink state machine, and ds->ops->phyread() will thus no longer call into the driver after this point.

In the second case, devclose(conduit) should do this, as per Documentation/networking/driver.rst:

| Quiescence | ---------- | | After the ndostop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands.

So it should be sufficient to ensure that later, when we zeroize conduit->dsaptr, there will be no concurrent dsaswitchrcv() call on this conduit.

The addition of the netifdevicedetach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them.

The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsaswitchshutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsaptr (one which doesn't ensure that the interfaces aren't up).

block: fix integer overflow in BLKSECDISCARD

ACPI: battery: Fix possible crash when unregistering a battery hook

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

wifi: ath9khtc: Use skbsetlength() for resetting urb before resubmit

Syzbot points out that skbtrim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling skbsetlength(skb, 0) directly. In addition, skbsetlength() already contains a call to skbresettailpointer(), so remove the redundant call.

The syzbot report came from ath9khifusbregincb(), but there's a similar usage of skbtrim() in ath9khifusbrxcb(), change both while we're at it.

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

net: avoid potential underflow in qdiscpktleninit() with UFO

After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtionethdrtoskb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet.

Then commit cf9acc90c80ec ("net: virtionethdrtoskb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic :

IPv4 SKBGSOUDP, gsosize=3, skb->len = 28.

When this packet arrives in qdiscpktleninit(), we end up with hdrlen = 28 (IPv4 header + UDP header), matching skb->len

Then the following sets gsosegs to 0 :

gsosegs = DIVROUNDUP(skb->len - hdrlen, shinfo->gsosize);

Then later we set qdiscskbcb(skb)->pktlen to back to zero :/

qdiscskbcb(skb)->pktlen += (gsosegs - 1) hdrlen;

This leads to the following crash in fqcodel [1]

qdiscpktleninit() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel.

This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug.

[1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: errorcode(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fqcodelenqueue (net/sched/schfqcodel.c:120 net/sched/schfqcodel.c:168 net/sched/schfqcodel.c:230) schfqcodel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a: 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB

Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---

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

sctp: set skstate back to CLOSED if autobind fails in sctplistenstart

In sctplistenstart() invoked by sctpinetlisten(), it should set the skstate back to CLOSED if sctpautobind() fails due to whatever reason.

Otherwise, next time when calling sctpinetlisten(), if sctpsk(sk)->reuse is already set via setsockopt(SCTPREUSEPORT), sctpsk(sk)->bindhash will be dereferenced as skstate is LISTENING, which causes a crash as bindhash is NULL.

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctpinetlisten+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: <TASK> syslistensocket net/socket.c:1883 [inline] syslisten+0x1b7/0x230 net/socket.c:1894 dosyslisten net/socket.c:1902 [inline]

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

net: add more sanity checks to qdiscpktleninit()

One path takes care of SKBGSODODGY, assuming skb->len is bigger than hdrlen.

virtionethdrtoskb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes.

It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes.

- 20 bytes of IPv4 header - 60 bytes TCP header - a small gsosize like 8

virtionethdrtoskb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gsosize.

We need to make detect this case to not underflow qdiscskbcb(skb)->pktlen.

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

drm/amd/display: Initialize getbytesperelement's default to 1

Variables, used as denominators and maybe not assigned to other values, should not be 0. bytesperelementy & bytesperelementc are initialized by getbytesperelement() which should never return 0.

This fixes 10 DIVIDEBYZERO issues reported by Coverity.

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

drm/amd/pm: ensure the fwinfo is not null before using it

This resolves the dereference null return value warning reported by Coverity.

ext4: update origpath in ext4findextent()

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

tpm: Clean up TPM space after command failure

tpmdevtransmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed.

Fix this by flushing the space in the event of command transmission failure.

erofs: handle overlapped pclusters out of crafted images properly

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

RDMA/hns: Fix spinunlockirqrestore() called with IRQs enabled

Fix missuse of spinlockirq()/spinunlockirq() when spinlockirqsave()/spinlockirqrestore() was hold.

This was discovered through the lock debugging, and the corresponding log is as follows:

rawlocalirqrestore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warnbogusirqrestore+0x30/0x40 ... Call trace: warnbogusirqrestore+0x30/0x40 rawspinunlockirqrestore+0x84/0xc8 addqptolist+0x11c/0x148 [hnsrocehwv2] hnsrocecreateqpcommon.constprop.0+0x240/0x780 [hnsrocehwv2] hnsrocecreateqp+0x98/0x160 [hnsrocehwv2] createqp+0x138/0x258 ibcreateqpkernel+0x50/0xe8 createmadqp+0xa8/0x128 ibmadportopen+0x218/0x448 ibmadinitdevice+0x70/0x1f8 addclientcontext+0xfc/0x220 enabledeviceandget+0xd0/0x140 ibregisterdevice.part.0+0xf4/0x1c8 ibregisterdevice+0x34/0x50 hnsroceregisterdevice+0x174/0x3d0 [hnsrocehwv2] hnsroceinit+0xfc/0x2c0 [hnsrocehwv2] hnsrocehwv2initinstance+0x7c/0x1d0 [hnsrocehwv2] hnsrocehwv2initinstance+0x9c/0x180 [hnsrocehwv2]

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

nfsd: call cacheput if xdrreservespace returns NULL

If not enough buffer space available, but idmaplookup has triggered lookupfn which calls cacheget and returns successfully. Then we missed to call cacheput here which pairs with cacheget.

Reviwed-by: Jeff Layton <jlayton@kernel.org>

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

sockmap: Add a condresched() in sockhashfree()

Several syzbot soft lockup reports all have in common sockhashfree()

If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.

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

ipv6: avoid possible NULL deref in rt6uncachedlistflushdev()

Blamed commit accidentally removed a check for rt->rt6iidev being NULL, as spotted by syzbot:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6uncachedlistflushdev net/ipv6/route.c:177 [inline] RIP: 0010:rt6disableip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> addrconfifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconfnotify+0x3cb/0x1020 notifiercallchain+0x19f/0x3e0 kernel/notifier.c:93 callnetdevicenotifiersextack net/core/dev.c:2032 [inline] callnetdevicenotifiers net/core/dev.c:2046 [inline] unregisternetdevicemanynotify+0xd81/0x1c40 net/core/dev.c:11352 unregisternetdevicemany net/core/dev.c:11414 [inline] unregisternetdevicequeue+0x303/0x370 net/core/dev.c:11289 unregisternetdevice include/linux/netdevice.h:3129 [inline] tundetach+0x6b9/0x1600 drivers/net/tun.c:685 tundetach drivers/net/tun.c:701 [inline] tunchrclose+0x108/0x1b0 drivers/net/tun.c:3510 fput+0x24a/0x8a0 fs/filetable.c:422 taskworkrun+0x24f/0x310 kernel/taskwork.c:228 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0xa2f/0x27f0 kernel/exit.c:882 dogroupexit+0x207/0x2c0 kernel/exit.c:1031 dosysexitgroup kernel/exit.c:1042 [inline] sesysexitgroup kernel/exit.c:1040 [inline] x64sysexitgroup+0x3f/0x40 kernel/exit.c:1040 x64syscall+0x2634/0x2640 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6uncachedlistflushdev net/ipv6/route.c:177 [inline] RIP: 0010:rt6disableip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---

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

can: bcm: Clear bo->bcmprocread after removeprocentry().

syzbot reported a warning in bcmrelease(). [0]

The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered.

However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcmprocread triggers unnecessary removeprocentry() in bcmrelease().

Let's clear bo->bcmprocread after removeprocentry() in bcmnotify().

[0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 removeprocentry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:removeprocentry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcmrelease+0x250/0x880 net/can/bcm.c:1578 sockrelease net/socket.c:659 [inline] sockclose+0xbc/0x240 net/socket.c:1421 fput+0x24a/0x8a0 fs/filetable.c:422 taskworkrun+0x24f/0x310 kernel/taskwork.c:228 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0xa2f/0x27f0 kernel/exit.c:882 dogroupexit+0x207/0x2c0 kernel/exit.c:1031 dosysexitgroup kernel/exit.c:1042 [inline] sesysexitgroup kernel/exit.c:1040 [inline] x64sysexitgroup+0x3f/0x40 kernel/exit.c:1040 x64syscall+0x2634/0x2640 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK>

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

wifi: mac80211: use two-phase skb reclamation in ieee80211dostop()

Since 'devqueuexmit()' should be called with interrupts enabled, the following backtrace:

ieee80211dostop() ... spinlockirqsave(&amp;local-&gt;queuestopreasonlock, flags) ... ieee80211freetxskb() ieee80211reportusedskb() ieee80211reportackskb() cfg80211mgmttxstatusext() nl80211frametxstatus() genlmsgmulticastnetns() genlmsgmulticastnetnsfiltered() nlmsgmulticastfiltered() netlinkbroadcastfiltered() doonebroadcast() netlinkbroadcastdeliver() netlinksendskb() netlinkdelivertap() netlinkdelivertapskb() devqueuexmit() devqueuexmit() ; with IRQS disabled ... spinunlockirqrestore(&amp;local-&gt;queuestopreasonlock, flags)

issues the warning (as reported by syzbot reproducer):

WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 localbhenableip+0xc3/0x120

Fix this by implementing a two-phase skb reclamation in 'ieee80211dostop()', where actual work is performed outside of a section with interrupts disabled.

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

nilfs2: fix potential null-ptr-deref in nilfsbtreeinsert()

Patch series "nilfs2: fix potential issues with empty b-tree nodes".

This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot.

This patch (of 3):

If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfsbtreeprepareinsert(), which is called from nilfsbtreeinsert().

This is because, when the number of child nodes of the b-tree root is 0, nilfsbtreedolookup() does not set the block buffer head in any of path[x].bpbh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfsbtreegetnonrootnode(), which accesses the buffer memory of path[x].bpbh, is called.

Fix this issue by adding a check to nilfsbtreerootbroken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency.

Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.

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

block: fix potential invalid pointer dereference in blkaddpartition

The blkaddpartition() function initially used a single if-condition (ISERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where mdautodetectdev() could be called without confirming that part is a valid pointer.

This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of mdautodetectdev() calls.

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

tcp: check skb is non-NULL in tcprtodeltaus()

We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcprearmrto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases:

Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: errorcode(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? showregs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? nocontext+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6protocoldeliverrcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6sublistrcvfinish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? badareanosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? badareanosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? douseraddrfault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6listrcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? dopagefault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? dopagefault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? pagefault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcpsendlossprobe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcpwritetimerhandler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcpwritetimer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcpwritetimerhandler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] calltimerfn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] runtimers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibratecpukhz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? nativex2apicicrwrite+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapicnexteven ---truncated---

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

nfsd: return -EINVAL when namelen is 0

When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdupuser() to return ZEROSIZEPTR. When we access the name.data that has been assigned the value of ZEROSIZEPTR in nfs4clienttoreclaim(), null pointer dereference is triggered.

[ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4clienttoreclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dumpstack+0x9a/0xd0 [ T1205] ? nfs4clienttoreclaim+0xe9/0x260 [ T1205] kasanreport.cold+0x34/0x84 [ T1205] ? nfs4clienttoreclaim+0xe9/0x260 [ T1205] kasanreport+0x3a/0x50 [ T1205] nfs4clienttoreclaim+0xe9/0x260 [ T1205] ? nfsd4releaselockowner+0x410/0x410 [ T1205] cldpipedowncall+0x5ca/0x760 [ T1205] ? nfsd4cldtrackingexit+0x1d0/0x1d0 [ T1205] ? downwritekillablenested+0x170/0x170 [ T1205] ? avcpolicyseqno+0x28/0x40 [ T1205] ? selinuxfilepermission+0x1b4/0x1e0 [ T1205] rpcpipewrite+0x84/0xb0 [ T1205] vfswrite+0x143/0x520 [ T1205] ksyswrite+0xc9/0x170 [ T1205] ? ia32sysread+0x50/0x50 [ T1205] ? ktimegetcoarserealts64+0xfe/0x110 [ T1205] ? ktimegetcoarserealts64+0xa2/0x110 [ T1205] dosyscall64+0x33/0x40 [ T1205] entrySYSCALL64afterhwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIGRAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ==================================================================

Fix it by checking namelen.

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:

ethtool: module: avoid leaking a netdev ref on module flash errors

moduleflashfwschedule() is missing undo for setting the "inprogress" flag and taking the netdev reference. Delay taking these, the device can't disappear while we are holding rtnllock.