drm/amdgpu: Using uninitialized value size when calling amdgpuvcecsreloc

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

nvmet: fix a possible leak when destroy a ctrl during qp establishment

In nvmetsqdestroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.

However, a small window is possible where nvmetsqdestroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before killandconfirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmetsqdestroy. This prevented the final reference drop on the ctrl.

Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.

This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.

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

wifi: mt76: replace skbput with skbputzero

Avoid potentially reusing uninitialized data

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

powerpc/eeh: avoid possible crash when edev->pdev changes

If a PCI device is removed during eehpereportedev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus.

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

drm/radeon: check bova->bo is non-NULL before using it

The call to radeonvmclearfreed might clear bova->bo, so we have to check it before dereferencing it.

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

firmware: csdsp: Use strnlen() on name fields in V1 wmfw files

Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files.

In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. csdsp should protect against overrunning the array if the NUL terminator is missing.

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

firmware: csdsp: Fix overflow checking of wmfw header

Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer.

The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs

wmfwheader + wmfwadsp1sizes + wmfwfooter

But wmfwadsp1sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfwadsp2sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfwadsp2sizes.

This patch splits the length check into three separate parts. Each of the wmfwheader, wmfwadsp?sizes and wmfwfooter are checked separately before they are used.

firmware: csdsp: Prevent buffer overrun when processing V2 alg headers

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

xfs: add bounds checking to xlogrecoverprocessdata

There is a lack of verification of the space occupied by fixed members of xlogopheader in the xlogrecoverprocessdata.

We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tailblk and headblk are the same, which will result in the inability to enter xlogrecoverprocessdata 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlogopheader entries only 1 byte away from xlogrecheader->hsize 5) xlogrecheader->hnumlogops++ 6) Modify xlogrecheader->hcrc

Fix: Add a check to make sure there is sufficient space to access fixed members of xlogopheader.

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

xfs: don't walk off the end of a directory data block

This adds sanity checks for xfsdir2dataunused and xfsdir2dataentry to make sure don't stray beyond valid memory region. Before patching, the loop simply checks that the start offset of the dup and dep is within the range. So in a crafted image, if last entry is xfsdir2dataunused, we can change dup->length to dup->length-1 and leave 1 byte of space. In the next traversal, this space will be considered as dup or dep. We may encounter an out of bound read when accessing the fixed members.

In the patch, we make sure that the remaining bytes large enough to hold an unused entry before accessing xfsdir2dataunused and xfsdir2dataunused is XFSDIR2DATAALIGN byte aligned. We also make sure that the remaining bytes large enough to hold a dirent with a single-byte name before accessing xfsdir2dataentry.

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

udp: Set SOCKRCUFREE earlier in udplibgetport().

syzkaller triggered the warning [0] in udpv4earlydemux().

In udpv[46]earlydemux() and sklookup(), we do not touch the refcount of the looked-up sk and use sockpfree() as skb->destructor, so we check SOCKRCUFREE to ensure that the sk is safe to access during the RCU grace period.

Currently, SOCKRCUFREE is flagged for a bound socket after being put into the hash table. Moreover, the SOCKRCUFREE check is done too early in udpv[46]earlydemux() and sklookup(), so there could be a small race window:

CPU1 CPU2 ---- ---- udpv4earlydemux() udplibgetport() | |- hlistaddheadrcu() |- sk = udp4libdemuxlookup() | |- DEBUGNETWARNONONCE(skisrefcounted(sk)); - socksetflag(sk, SOCKRCUFREE)

We had the same bug in TCP and fixed it in commit 871019b22d1b ("net: set SOCKRCUFREE before inserting socket into hashtable").

Let's apply the same fix for UDP.

[0]: WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udpv4earlydemux+0x481/0xb70 net/ipv4/udp.c:2599 Modules linked in: CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:udpv4earlydemux+0x481/0xb70 net/ipv4/udp.c:2599 Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52 RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001 RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680 R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> iprcvfinishcore.constprop.0+0xbdd/0xd20 net/ipv4/ipinput.c:349 iprcvfinish+0xda/0x150 net/ipv4/ipinput.c:447 NFHOOK include/linux/netfilter.h:314 [inline] NFHOOK include/linux/netfilter.h:308 [inline] iprcv+0x16c/0x180 net/ipv4/ipinput.c:569 netifreceiveskbonecore+0xb3/0xe0 net/core/dev.c:5624 netifreceiveskb+0x21/0xd0 net/core/dev.c:5738 netifreceiveskbinternal net/core/dev.c:5824 [inline] netifreceiveskb+0x271/0x300 net/core/dev.c:5884 tunrxbatched drivers/net/tun.c:1549 [inline] tungetuser+0x24db/0x2c50 drivers/net/tun.c:2002 tunchrwriteiter+0x107/0x1a0 drivers/net/tun.c:2048 newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x76f/0x8d0 fs/readwrite.c:590 ksyswrite+0xbf/0x190 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x41/0x50 fs/readwrite.c:652 x64syscall+0xe66/0x1990 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x4b/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7fc44a68bc1f Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48 RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f R ---truncated---

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

filelock: Remove locks reliably when fcntl/close race is detected

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024072314-CVE-2024-41012-a1cf@gregkh/T

A denial-of-service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet (i.e. size < ETHHLEN). The packet may traverse through vhost-net, macvtap and vlan without any validation/drop. When this packet is presented to mlx5 driver on the host side, the kernel panic happens since mlx5core assumes the frame size is always >= ETHHLEN.

This vulnerability affects both drivers/net/tun.c and drivers/net/tap.c. CVE-2024-41091 has been assigned to the TUN side of the issue.

Reference: https://www.openwall.com/lists/oss-security/2024/07/24/4

A denial-of-service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet (i.e. size < ETHHLEN). The packet may traverse through vhost-net, macvtap and vlan without any validation/drop. When this packet is presented to mlx5 driver on the host side, the kernel panic happens, since mlx5core assumes the frame size is always >= ETHHLEN.

This vulnerability affects both drivers/net/tun.c and drivers/net/tap.c. CVE-2024-41090 has been assigned to the TAP side of the issue.

Reference: https://www.openwall.com/lists/oss-security/2024/07/24/4

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

HID: hid-thrustmaster: fix OOB read in thrustmasterinterrupts

Syzbot reported an slab-out-of-bounds Read in thrustmasterprobe() bug. The root case is in missing validation check of actual number of endpoints.

Code should not blindly access usbhostinterface::endpoint array, since it may contain less endpoints than code expects.

Fix it by adding missing validaion check and print an error if number of endpoints do not match expected number

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

net/sunrpc: fix reference count leaks in rpcsysfsxprtstatechange

The refcount leak issues take place in an error handling path. When the 3rd argument buf doesn't match with "offline", "online" or "remove", the function simply returns -EINVAL and forgets to decrease the reference count of a rpcxprt object and a rpcxprtswitch object increased by rpcsysfsxprtkobjgetxprt() and rpcsysfsxprtkobjgetxprtswitch(), causing reference count leaks of both unused objects.

Fix this issue by jumping to the error handling path labelled with output when buf matches none of "offline", "online" or "remove".

drm/amdgpu: change vm->taskinfo handling

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

tcp: avoid too many retransmit packets

If a TCP socket is using TCPUSERTIMEOUT, and the other peer retracted its window to zero, tcpretransmittimer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCPUSERTIMEOUT has 'expired'.

The fix is to make sure tcprtxprobe0timedout() takes icsk->icskusertimeout into account.

Before blamed commit, the socket would not timeout after icsk->icskusertimeout, but would use standard exponential backoff for the retransmits.

Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when sndwnd is 0"), the issue would last 2 minutes instead of 4.

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

wifi: iwlwifi: mvm: check nssids before accessing the ssids

In some versions of cfg80211, the ssids poinet might be a valid one even though nssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking nssids first.

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

ionic: fix use after netifnapidel()

When queues are started, netifnapiadd() and napienable() are called. If there are 4 queues and only 3 queues are used for the current configuration, only 3 queues' napi should be registered and enabled. The ionicqcqenable() checks whether the .poll pointer is not NULL for enabling only the using queue' napi. Unused queues' napi will not be registered by netifnapiadd(), so the .poll pointer indicates NULL. But it couldn't distinguish whether the napi was unregistered or not because netifnapidel() doesn't reset the .poll pointer to NULL. So, ionicqcqenable() calls napienable() for the queue, which was unregistered by netifnapidel().

Reproducer: ethtool -L <interface name> rx 1 tx 1 combined 0 ethtool -L <interface name> rx 0 tx 0 combined 1 ethtool -L <interface name> rx 0 tx 0 combined 4

Splat looks like: kernel BUG at net/core/dev.c:6666! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16 Workqueue: events ioniclifdeferredwork [ionic] RIP: 0010:napienable+0x3b/0x40 Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? die+0x33/0x90 ? dotrap+0xd9/0x100 ? napienable+0x3b/0x40 ? doerrortrap+0x83/0xb0 ? napienable+0x3b/0x40 ? napienable+0x3b/0x40 ? excinvalidop+0x4e/0x70 ? napienable+0x3b/0x40 ? asmexcinvalidop+0x16/0x20 ? napienable+0x3b/0x40 ionicqcqenable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionicstartqueues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ioniclinkstatuscheck+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ioniclifdeferredwork+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] processonework+0x145/0x360 workerthread+0x2bb/0x3d0 ? pfxworkerthread+0x10/0x10 kthread+0xcc/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x2d/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30

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

wifi: cfg80211: Lock wiphy in cfg80211getstation

Wiphy should be locked before calling rdevgetstation() (see lockdep assert in ieee80211getstation()).

This fixes the following kernel NULL dereference:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3mesong12a dwc3ofsimple dwc3 ipgre gre ath10kpci ath10kcore ath9k ath9kcommon ath9khw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: batevents batadvvelpthroughputmetricupdate pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10kstastatistics+0x10/0x2dc [ath10kcore] lr : stasetsinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10kstastatistics+0x10/0x2dc [ath10kcore] stasetsinfo+0xcc/0xbd4 ieee80211getstation+0x2c/0x44 cfg80211getstation+0x80/0x154 batadvvelpgetthroughput+0x138/0x1fc batadvvelpthroughputmetricupdate+0x1c/0xa4 processonework+0x1ec/0x414 workerthread+0x70/0x46c kthread+0xdc/0xe0 retfromfork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)

This happens because STA has time to disconnect and reconnect before batadvvelpthroughputmetricupdate() delayed work gets scheduled. In this situation, ath10kstastate() can be in the middle of resetting arsta data when the work queue get chance to be scheduled and ends up accessing it. Locking wiphy prevents that.

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

scsi: mpt3sas: Avoid test/setbit() operating in non-allocated memory

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024071207-CVE-2024-40901-05c4@gregkh/T

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

xhci: Handle TD clearing for multiple streams case

When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhciinvalidatecancelledtds() again from xhcihandlecmdsetdeq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhciwarn() if this ever happens.

This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious).

Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again.

[Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.]

Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhcidbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhcidbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn't really hint at there being a problem at all).

It took me months of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn't have been left in at all).

Another fix to solve clearing the caches of all stream rings with cancelled TDs is needed, but not as urgent.

3 years after that statement and 14 years after the original bug was introduced, I think it's finally time to fix it. And maybe next time let's not leave bugs unfixed (that are actually worse than the original bug), and let's actually get people to review kernel commits please.

Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use hdparm to mark an early sector (e.g. 1024) on a disk as bad, then cat /dev/sdX > /dev/null in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn't get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the cat in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro'd and tested on an Apple M1 Mac Mini (dwc3 host).

On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a ---truncated---

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

vmci: prevent speculation leaks by sanitizing event in eventdeliver()

Coverity spotted that eventmsg is controlled by user-space, eventmsg->eventdata.event is passed to eventdeliver() and used as an index without sanitization.

This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.

Only compile tested, no access to HW.

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

wifi: iwlwifi: mvm: don't read past the mfuart notifcation

In case the firmware sends a notification that claims it has more data than it has, we will read past that was allocated for the notification. Remove the print of the buffer, we won't see it by default. If needed, we can see the content with tracing.

This was reported by KFENCE.

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

netns: Make getnetns() handle zero refcount net

Syzkaller hit a warning: refcountt: addition on 0; use-after-free. WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcountwarnsaturate+0xdf/0x1d0 Modules linked in: CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:refcountwarnsaturate+0xdf/0x1d0 Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1 RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001 RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139 R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4 R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040 FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? showregs+0xa3/0xc0 ? warn+0xa5/0x1c0 ? refcountwarnsaturate+0xdf/0x1d0 ? reportbug+0x1fc/0x2d0 ? refcountwarnsaturate+0xdf/0x1d0 ? handlebug+0xa1/0x110 ? excinvalidop+0x3c/0xb0 ? asmexcinvalidop+0x1f/0x30 ? warnprintk+0xcc/0x140 ? warnprintk+0xd5/0x140 ? refcountwarnsaturate+0xdf/0x1d0 getnetns+0xa4/0xc0 ? pfxgetnetns+0x10/0x10 openrelatedns+0x5a/0x130 tunchrioctl+0x1616/0x2370 ? sanitizercovtraceswitch+0x58/0xa0 ? sanitizercovtraceconstcmp2+0x1c/0x30 ? pfxtunchrioctl+0x10/0x10 tunchrioctl+0x2f/0x40 x64sysioctl+0x11b/0x160 x64syscall+0x1211/0x20d0 dosyscall64+0x9e/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f5b28f165d7 Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8 RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7 RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003 RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0 R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730 R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: kernel: paniconwarn set ...

This is trigger as below: ns0 ns1 tunsetiff() //dev is tun0 tun->dev = dev //ip link set tun0 netns ns1 putnet() //ref is 0 tunchrioctl() //TUNGETDEVNETNS net = devnet(tun->dev); openrelatedns(&net->ns, getnetns); //ns1 getnetns() getnet() //addition on 0

Use maybegetnet() in getnetns in case net's ref is zero to fix this

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

powerpc/pseries: Enforce hcall result buffer validity and size

plparhcall(), plparhcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea.

For example, if I write a bug like this:

long retbuf[PLPARHCALLBUFSIZE]; // should be PLPARHCALL9BUFSIZE plparhcall9(HALLOCATEVASWINDOW, retbuf, ...);

This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plparhcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.)

To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this:

error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plparhcall9(HALLOCATEVASWINDOW, retbuf, | ^ ~~~~~~

[1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes.

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

KVM: arm64: Disassociate vcpus from redistributor region on teardown

When tearing down a redistributor region, make sure we don't have any dangling pointer to that region stored in a vcpu.

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

scsi: qedi: Fix crash while reading debugfs attribute

The qedidbgdonotrecovercmdread() function invokes sprintf() directly on a user pointer, which results into the crash.

To fix this issue, use a small local stack buffer for sprintf() and then call simplereadfrombuffer(), which in turns make the copytouser() call.

BUG: unable to handle page fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops: 0002 [#1] PREEMPT SMP PTI Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023 RIP: 0010:memcpyorig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? diebody+0x1a/0x60 ? pagefaultoops+0x183/0x510 ? excpagefault+0x69/0x150 ? asmexcpagefault+0x22/0x30 ? memcpyorig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedidbgdonotrecovercmdread+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] fullproxyread+0x50/0x80 vfsread+0xa5/0x2e0 ? folioaddnewanonrmap+0x44/0xa0 ? setpteat+0x15/0x30 ? doptemissing+0x426/0x7f0 ksysread+0xa5/0xe0 dosyscall64+0x58/0x80 ? countmemcgevents+0x46/0x90 ? countmemcgeventmm+0x3d/0x60 ? handlemmfault+0x196/0x2f0 ? douseraddrfault+0x267/0x890 ? excpagefault+0x69/0x150 entrySYSCALL64afterhwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d

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

net: do not leave a dangling sk pointer, when socket creation fails

It is possible to trigger a use-after-free by: attaching an fentry probe to sockrelease() and the probe calling the bpfgetsocketcookie() helper running traceroute -I 1.1.1.1 on a freshly booted VM

A KASAN enabled kernel will log something like below (decoded and stripped): ================================================================== BUG: KASAN: slab-use-after-free in sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299

CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: dumpstacklvl (lib/dumpstack.c:117 (discriminator 1)) printreport (mm/kasan/report.c:378 mm/kasan/report.c:488) ? sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasanreport (mm/kasan/report.c:603) ? sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasancheckrange (mm/kasan/generic.c:183 mm/kasan/generic.c:189) sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) bpfgetsocketptrcookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sockdiag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpfprog875642cf11f1d139sockrelease+0x6e/0x8e bpftrampoline6442506592+0x47/0xaf sockrelease (net/socket.c:652) sockcreate (net/socket.c:1601) ... Allocated by task 299 on cpu 2 at 78.328492s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasanslaballoc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmemcacheallocnoprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) skprotalloc (net/core/sock.c:2075) skalloc (net/core/sock.c:2134) inetcreate (net/ipv4/afinet.c:327 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1572) syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Freed by task 299 on cpu 2 at 78.328502s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasansavefreeinfo (mm/kasan/generic.c:582) poisonslabobject (mm/kasan/common.c:242) kasanslabfree (mm/kasan/common.c:256) kmemcachefree (mm/slub.c:4437 mm/slub.c:4511) skdestruct (net/core/sock.c:2117 net/core/sock.c:2208) inetcreate (net/ipv4/afinet.c:397 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1572) syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Fix this by clearing the struct socket reference in skcommonrelease() to cover all protocol families create functions, which may already attached the reference to the sk object with sockinitdata().