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

ipv6: Fix potential uninit-value access in ip6makeskb()

As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in ipmakeskb()") for IPv4, check FLOWIFLAGKNOWNNH on fl6->flowi6flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access.

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

ipv4: Fix uninit-value access in ipmakeskb()

KMSAN reported uninit-value access in ipmakeskb() [1]. ipmakeskb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IPHDRINCL changes HDRINCL while ipmakeskb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN.

Check FLOWIFLAGKNOWNNH on fl4->flowi4flags instead of testing HDRINCL on the socket.

Also, fl4->fl4icmptype and fl4->fl4icmpcode are not initialized. These are union in struct flowi4 and are implicitly initialized by flowi4initoutput(), but we should not rely on specific union layout.

Initialize these explicitly in rawsendmsg().

[1] BUG: KMSAN: uninit-value in ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 ipfinishskb include/net/ip.h:243 [inline] ippushpendingframes+0x4c/0x5c0 net/ipv4/ipoutput.c:1508 rawsendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x274/0x3c0 net/socket.c:745 syssendto+0x62c/0x7b0 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x5f6/0xc50 mm/slub.c:3888 kmallocreserve+0x13c/0x4a0 net/core/skbuff.c:577 allocskb+0x35a/0x7c0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1318 [inline] ipappenddata+0x49ab/0x68c0 net/ipv4/ipoutput.c:1128 ipappenddata+0x1e7/0x260 net/ipv4/ipoutput.c:1365 rawsendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x274/0x3c0 net/socket.c:745 syssendto+0x62c/0x7b0 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x6d/0x75

CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014

In multiple locations, there is a possible way to conduct local privilege escalation due to memory corruption. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

In binderalloccopytobuffer of binder.c, there is a possible arbitrary code execution due to a use after free. This could lead to local escalation of privilege in the kernel with no additional execution privileges needed. User interaction is not needed for exploitation.

In multiple locations, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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

KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgicv2parseattr()

The Linux kernel CVE team has assigned CVE-2024-36953 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024053040-CVE-2024-36953-fc12@gregkh/T

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

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until busresetwork has serviced and cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCIPARAMDEBUGBUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them.

irqhandler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irqhandler, because we won't service the event until later. irqhandler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irqhandler being called again each time it exits. This freeze can be reproduced by loading firewireohci with "modprobe firewireohci debug=-1" (to enable all debugging output). Apparently there are also some cases where busresetwork will get called soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization.

irqhandler will now leave the event flag set but mask bus reset interrupts, so irqhandler won't be called again and there will be no freeze. If OHCIPARAMDEBUGBUSRESETS is enabled, busresetwork will unmask the interrupt after servicing the event, so future interrupts will be caught as desired.

As a side effect to this change, OHCIPARAMDEBUGBUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after busresetwork has executed.

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

fs/9p: only translate RWX permissions for plain 9P2000

Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.

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

drm/amdkfd: don't allow mapping the MMIO HDP page with large pages

We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGESIZE of MMIO space.

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

scsi: lpfc: Release hbalock before calling lpfcworkerwakeup()

lpfcworkerwakeup() calls the lpfcworkdone() routine, which takes the hbalock. Thus, lpfcworkerwakeup() should not be called while holding the hbalock to avoid potential deadlock.

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

wifi: nl80211: don't free NULL coalescing rule

If the parsing fails, we can dereference a NULL pointer here.

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

nfs: Handle error of rpcprocregister() in nfsnetinit().

syzkaller reported a warning [0] triggered while destroying immature netns.

rpcprocregister() was called in initnfsfs(), but its error has been ignored since at least the initial commit 1da177e4c3f4 ("Linux-2.6.12-rc2").

Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces") converted the procfs to per-netns and made the problem more visible.

Even when rpcprocregister() fails, nfsnetinit() could succeed, and thus nfsnetexit() will be called while destroying the netns.

Then, removeprocentry() will be called for non-existing proc directory and trigger the warning below.

Let's handle the error of rpcprocregister() properly in nfsnetinit().

[0]: name 'nfs' WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 removeprocentry+0x1bb/0x2d0 fs/proc/generic.c:711 Modules linked in: CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:removeprocentry+0x1bb/0x2d0 fs/proc/generic.c:711 Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8 FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> rpcprocunregister+0x64/0x70 net/sunrpc/stats.c:310 nfsnetexit+0x1c/0x30 fs/nfs/inode.c:2438 opsexitlist+0x62/0xb0 net/core/netnamespace.c:170 setupnet+0x46c/0x660 net/core/netnamespace.c:372 copynetns+0x244/0x590 net/core/netnamespace.c:505 createnewnamespaces+0x2ed/0x770 kernel/nsproxy.c:110 unsharensproxynamespaces+0xae/0x160 kernel/nsproxy.c:228 ksysunshare+0x342/0x760 kernel/fork.c:3322 dosysunshare kernel/fork.c:3393 [inline] sesysunshare kernel/fork.c:3391 [inline] x64sysunshare+0x1f/0x30 kernel/fork.c:3391 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x4f/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x46/0x4e RIP: 0033:0x7f30d0febe5d 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 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIGRAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600 RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000 </TASK>

amd/amdkfd: sync all devices to wait all processes being evicted

drm/amdkfd: range check cp bad op exception interrupts

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

drm/vmwgfx: Fix invalid reads in fence signaled events

Correctly set the length of the drmevent to the size of the structure that's actually used.

The length of the drmevent was set to the parent structure instead of to the drmvmweventfence which is supposed to be read. drmread uses the length parameter to copy the event to the user space thus resuling in oob reads.

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

epoll: be better about file lifetimes

epoll can call out to vfspoll() with a file pointer that may race with the last 'fput()'. That would make fcount go down to zero, and while the ep->mtx locking means that the resulting file pointer tear-down will be blocked until the poll returns, it means that fcount is already dead, and any use of it won't actually get a reference to the file any more: it's dead regardless.

Make sure we have a valid ref on the file pointer before we call down to vfspoll() from the epoll routines.

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

drm/amdgpu/mes: fix use-after-free issue

Delete fence fallback timer to fix the ramdom use-after-free issue.

v2: move to amdgpumes.c

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

dyndbg: fix old BUGON in >control parser

Fix a BUGON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing prerr and return -EINVAL instead.

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

rtnetlink: Correct nested IFLAVFVLANLIST attribute validation

Each attribute inside a nested IFLAVFVLANLIST is assumed to be a struct iflavfvlaninfo so the size of such attribute needs to be at least of sizeof(struct iflavfvlaninfo) which is 14 bytes. The current size validation in dosetvfinfo is against NLAHDRLEN (4 bytes) which is less than sizeof(struct iflavfvlaninfo) so this validation is not enough and a too small attribute might be cast to a struct iflavfvlaninfo, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.

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

wifi: iwlwifi: read txq->readptr under lock

If we read txq->readptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARNONCE() a little later. Fix that by reading txq->readptr under lock.

drm/amd/display: Skip on writeback when it's not applicable

block: fix overflow in blkioctldiscard()

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

tcp: Use refcountincnotzero() in tcptwskunique().

Anderson Nascimento reported a use-after-free splat in tcptwskunique() with nice analysis.

Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inettwskhashdance() sets TIME-WAIT socket's skrefcnt after putting it into ehash and releasing the bucket lock.

Thus, there is a small race window where other threads could try to reuse the port during connect() and call sockhold() in tcptwskunique() for the TIME-WAIT socket with zero refcnt.

If that happens, the refcnt taken by tcptwskunique() is overwritten and sockput() will cause underflow, triggering a real use-after-free somewhere else.

To avoid the use-after-free, we need to use refcountincnotzero() in tcptwskunique() and give up on reusing the port if it returns false.

[0]: refcountt: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcountwarnsaturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x8664 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcountwarnsaturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcountwarnsaturate+0xe5/0x110 ? warn+0x81/0x130 ? refcountwarnsaturate+0xe5/0x110 ? reportbug+0x171/0x1a0 ? refcountwarnsaturate+0xe5/0x110 ? handlebug+0x3c/0x80 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? refcountwarnsaturate+0xe5/0x110 tcptwskunique+0x186/0x190 inetcheckestablished+0x176/0x2d0 inethashconnect+0x74/0x7d0 ? pfxinetcheckestablished+0x10/0x10 tcpv4connect+0x278/0x530 inetstreamconnect+0x10f/0x3d0 inetstreamconnect+0x3a/0x60 sysconnect+0xa8/0xd0 x64sysconnect+0x18/0x20 dosyscall64+0x83/0x170 entrySYSCALL64afterhwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>

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

s390/qeth: Fix kernel panic after setting hsuid

Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL.

Example: --------------------------------------------------------------------------- [ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: afiucv qethl3 zfcp scsitransportfc sunrpc nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftablesset nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables libcrc32c nfnetlink ghashs390 prng xts aess390 dess390 de sgeneric sha3512s390 sha3256s390 sha512s390 vfioccw vfiomdev mdev vfioiommutype1 eadmsch vfio ext4 mbcache jbd2 qethl2 bridge stp llc dasdeckdmod qeth dasdmod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stressclient Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] netrxaction+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] dosoftirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] dosoftirqownstack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] dosoftirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] localbhenableip+0x80/0x98 [ 2057.572825] [<0000000091314706>] devqueuexmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucvhssend+0x24e/0x300 [afiucv] [ 2057.572830] [<000003ff803dd88a>] iucvsendctrl+0x102/0x138 [afiucv] [ 2057.572833] [<000003ff803de72a>] iucvsockconnect+0x37a/0x468 [afiucv] [ 2057.572835] [<00000000912e7e90>] sysconnect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] syssocketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] systemcall+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] napipoll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt -------------------------------------------------------------------------------------------

Analysis: There is one napi structure per outq: card->qdio.outqs[i].napi The napi.poll functions are set during qethopen().

Since commit 1cfef80d4c2b ("s390/qeth: Don't call devclose/devopen (DOWN/UP)") qethsetoffline()/qethsetonline() no longer call devclose()/ devopen(). So if qethfreeqdioqueues() cleared card->qdio.outqs[i].napi.poll while the network interface was UP and the card was offline, they are not set again.

Reproduction: chzdev -e $devno layer2=0 ip link set dev $networkinterface up echo 0 > /sys/bus/ccw ---truncated---

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

nfc: llcp: fix nfcllcpsetsockopt() unsafe copies

syzbot reported unsafe calls to copyfromsockptr() [1]

Use copysafefromsockptr() instead.

[1]

BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078

CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 copyfromsockptroffset include/linux/sockptr.h:49 [inline] copyfromsockptr include/linux/sockptr.h:55 [inline] nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 dosocksetsockopt+0x3b1/0x720 net/socket.c:2311 syssetsockopt+0x1ae/0x250 net/socket.c:2334 dosyssetsockopt net/socket.c:2343 [inline] sesyssetsockopt net/socket.c:2340 [inline] x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfd/0x240 entrySYSCALL64afterhwframe+0x6d/0x75 RIP: 0033:0x7f7fac07fd89 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIGRAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89 RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

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

tcp: defer shutdown(SENDSHUTDOWN) for TCPSYNRECV sockets

TCPSYNRECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.

In the following crash [1], syzbot managed to trigger a divide by zero in tcprcvspaceadjust()

A socket makes the following state transitions, without ever calling tcpinittransfer(), meaning tcpinitbufferspace() is also not called.

TCPCLOSE connect() TCPSYNSENT TCPSYNRECV shutdown() -> tcpshutdown(sk, SENDSHUTDOWN) TCPFINWAIT1

To fix this issue, change tcpshutdown() to not perform a TCPSYNRECV -> TCPFINWAIT1 transition, which makes no sense anyway.

When tcprcvstateprocess() later changes socket state from TCPSYNRECV to TCPESTABLISH, then look at sk->skshutdown to finally enter TCPFINWAIT1 state, and send a FIN packet from a sane socket state.

This means tcpsendfin() can now be called from BH context, and must use GFPATOMIC allocations.

[1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcprcvspaceadjust+0x2df/0x890 net/ipv4/tcpinput.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: tcprecvmsglocked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcprecvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6recvmsg+0x16a/0x730 net/ipv6/afinet6.c:680 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x109/0x280 net/socket.c:1068 sysrecvmsg+0x1db/0x470 net/socket.c:2803 sysrecvmsg net/socket.c:2845 [inline] dorecvmmsg+0x474/0xae0 net/socket.c:2939 sysrecvmmsg net/socket.c:3018 [inline] dosysrecvmmsg net/socket.c:3041 [inline] sesysrecvmmsg net/socket.c:3034 [inline] x64sysrecvmmsg+0x199/0x250 net/socket.c:3034 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIGRAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001

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

scsi: bnx2fc: Remove spinlockbh while releasing resources after upload

The Linux kernel CVE team has assigned CVE-2024-36919 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024053039-CVE-2024-36919-9b97@gregkh/T

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

net: core: reject skbcopy(expand) for fraglist GSO skbs

SKBGSOFRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skbcopy or skbcopyexpand, in order to prevent a crash on a potential later call to skbgsosegment.

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

bna: ensure the copied buf is NUL terminated

Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdupusernul instead of memdupuser.

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

ALSA: hda: intel-sdw-acpi: fix usage of devicegetnamedchildnode()

The documentation for devicegetnamedchildnode() mentions this important point:

" The caller is responsible for calling fwnodehandleput() on the returned fwnode pointer. "

Add fwnodehandleput() to avoid a leaked reference.