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:

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:

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:

tracefs: Reset permissions on remount if permissions are options

There's an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode's permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs).

But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated.

This can cause security issues if a file's permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some.

For example:

# cd /sys/kernel/tracing # chgrp 1002 currenttracer # ls -l [..] -rw-r----- 1 root root 0 May 1 21:25 buffersizekb -rw-r----- 1 root root 0 May 1 21:25 buffersubbufsizekb -r--r----- 1 root root 0 May 1 21:25 buffertotalsizekb -rw-r----- 1 root lkp 0 May 1 21:25 currenttracer -rw-r----- 1 root root 0 May 1 21:25 dynamicevents -r--r----- 1 root root 0 May 1 21:25 dynftracetotalinfo -r--r----- 1 root root 0 May 1 21:25 enabledfunctions

Where currenttracer now has group "lkp".

# mount -o remount,gid=1001 . # ls -l -rw-r----- 1 root tracing 0 May 1 21:25 buffersizekb -rw-r----- 1 root tracing 0 May 1 21:25 buffersubbufsizekb -r--r----- 1 root tracing 0 May 1 21:25 buffertotalsizekb -rw-r----- 1 root lkp 0 May 1 21:25 currenttracer -rw-r----- 1 root tracing 0 May 1 21:25 dynamicevents -r--r----- 1 root tracing 0 May 1 21:25 dynftracetotalinfo -r--r----- 1 root tracing 0 May 1 21:25 enabledfunctions

Everything changed but the "currenttracer".

Add a new link list that keeps track of all the tracefsinodes which has the permission flags that tell if the file/dir should use the root inode's permission or not. Then on remount, clear all the flags so that the default behavior of using the root inode's permission is done for all files and directories.

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

thermal/debugfs: Fix two locking issues with thermal zone debug

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024060344-CVE-2024-36961-58bb@gregkh/T

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/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:

btrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer

Btrfs clears the content of an extent buffer marked as EXTENTBUFFERZONEDZEROOUT before the bio submission. This mechanism is introduced to prevent a write hole of an extent buffer, which is once allocated, marked dirty, but turns out unnecessary and cleaned up within one transaction operation.

Currently, btrfsclearbufferdirty() marks the extent buffer as EXTENTBUFFERZONEDZEROOUT, and skips the entry function. If this call happens while the buffer is under IO (with the WRITEBACK flag set, without the DIRTY flag), we can add the ZEROOUT flag and clear the buffer's content just before a bio submission. As a result:

1) it can lead to adding faulty delayed reference item which leads to a FS corrupted (EUCLEAN) error, and

2) it writes out cleared tree node on disk

The former issue is previously discussed in [1]. The corruption happens when it runs a delayed reference update. So, on-disk data is safe.

[1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/

The latter one can reach on-disk data. But, as that node is already processed by btrfsclearbufferdirty(), that will be invalidated in the next transaction commit anyway. So, the chance of hitting the corruption is relatively small.

Anyway, we should skip flagging ZEROOUT on a non-DIRTY extent buffer, to keep the content under IO intact.

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

octeontx2-af: fix the double free in rvunpcfreemem()

Clang static checker(scan-build) warning： drivers/net/ethernet/marvell/octeontx2/af/rvunpc.c:line 2184, column 2 Attempt to free released memory.

npcmcamrsrcsdeinit() has released 'mcam->counters.bmap'. Deleted this redundant kfree() to fix this double free problem.

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

Bluetooth: qca: fix info leak when fetching board id

Add the missing sanity check when fetching the board id to avoid leaking slab data when later requesting the firmware.

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

Bluetooth: qca: fix info leak when fetching fw build id

Add the missing sanity checks and move the 255-byte build-id buffer off the stack to avoid leaking stack data through debugfs in case the build-info reply is malformed.

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

net: fix out-of-bounds access in opsinit

netallocgeneric is called by netalloc, which is called without any locking. It reads maxgenptrs, which is changed under pernetopsrwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access.

It is possible that the array is allocated and another thread is registering a new pernet ops, increments maxgenptrs, which is then used to set s.len with a larger than allocated length for the variable array.

Fix it by reading maxgenptrs only once in netallocgeneric. If maxgenptrs is later incremented, it will be caught in netassigngeneric.

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

blk-iocost: do not WARN if iocg was already offlined

In iocgpaydebt(), warn is triggered if 'activelist' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocgwaitqtimerfn() is run at that time:

WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocgpaydebt+0x14c/0x190 Call trace: iocgpaydebt+0x14c/0x190 iocgkickwaitq+0x438/0x4c0 iocgwaitqtimerfn+0xd8/0x130 runhrtimer+0x144/0x45c hrtimerrunqueues+0x16c/0x244 hrtimerinterrupt+0x2cc/0x7b0

The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'activelist' is irrelevant, and 'waitqtimer' is canceled after removing 'activelist' in iocpdfree(), which ensures iocg is freed after iocgwaitqtimerfn() returns.

Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk.

gpiolib: cdev: Fix use after free in lineinfochangednotify

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

usb: gadget: ffs: Fix race between aiocancel() and AIO request complete

FFS based applications can utilize the aiocancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following:

DWC3 Gadget FFS Application dwc3gadgetsoftdisconnect() ... --> dwc3stopactivetransfers() --> dwc3gadgetgiveback(-ESHUTDOWN) --> ffsepfileasynciocomplete() ffsaiocancel() --> usbepfreerequest() --> usbepdequeue()

There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (iodata->req) the FFS application is also referencing it for the usbepdequeue() call. This can lead to accessing a stale/hanging pointer.

commit b566d38857fc ("usb: gadget: ffs: use iodata->status consistently") relocated the usbepfreerequest() into ffsepfileasynciocomplete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffsepfileasynciocomplete(), as usbepdequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock.

Fix this issue by moving the usbepfreerequest() back to ffsusercopyworker(), and ensuring that it explicitly sets iodata->req to NULL after freeing it within the ffs->epslock. This resolves the race condition above, as the ffsaiocancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffsusercopywork() not freeing the USB request until the AIO cancel is done referencing it.

This fix depends on commit b566d38857fc ("usb: gadget: ffs: use iodata->status consistently")

gpiolib: cdev: fix uninitialised kfifo

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

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:

usb: gadget: uvc: use correct buffer size when parsing configfs lists

This commit fixes uvc gadget support on 32-bit platforms.

Commit 0df28607c5cb ("usb: gadget: uvc: Generalise helper functions for reuse") introduced a helper function uvcgiteritementries() to aid with parsing lists of items on configfs attributes stores. This function is a generalization of another very similar function, which used a stack-allocated temporary buffer of fixed size for each item in the list and used the sizeof() operator to check for potential buffer overruns. The new function was changed to allocate the now variably sized temp buffer on heap, but wasn't properly updated to also check for max buffer size using the computed size instead of sizeof() operator.

As a result, the maximum item size was 7 (plus null terminator) on 64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just barely enough, 3 is definitely too small for some of UVC configfs attributes. For example, dwFrameInteval, specified in 100ns units, usually has 6-digit item values, e.g. 166666 for 60fps.

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:

blk-iocost: avoid out of bounds shift

UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures.

[ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0fbk700debugrc2kbuilder0gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F093A23 12/08/2020 Call Trace: <IRQ> dumpstacklvl+0x8f/0xe0 ubsanhandleshiftoutofbounds+0x22c/0x280 iocgkickdelay+0x30b/0x310 ioctimerfn+0x2fb/0x1f80 runtimerbase+0x1b6/0x250 ...

Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large.

I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug.

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

ARM: 9381/1: kasan: clear stale stack poison

We found below OOB crash:

[ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refreshcpuvmstats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwindbacktrace from showstack+0x18/0x1c [ 33.458326] showstack from dumpstacklvl+0x40/0x4c [ 33.459072] dumpstacklvl from printreport+0x158/0x4a4 [ 33.459863] printreport from kasanreport+0x9c/0x148 [ 33.460616] kasanreport from kasancheckrange+0x94/0x1a0 [ 33.461424] kasancheckrange from memset+0x20/0x3c [ 33.462157] memset from refreshcpuvmstats.constprop.0+0xcc/0x2ec [ 33.463064] refreshcpuvmstats.constprop.0 from ticknohzidlestoptick+0x180/0x53c [ 33.464181] ticknohzidlestoptick from doidle+0x264/0x354 [ 33.465029] doidle from cpustartupentry+0x20/0x24 [ 33.465769] cpustartupentry from restinit+0xf0/0xf4 [ 33.466528] restinit from archpostacpisubsysinit+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refreshcpuvmstats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'globalzonediff' [ 33.470729] [112, 276) 'globalnodediff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ==================================================================

We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle.

This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.

From cited commit [1] that explain the problem

Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning.

In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned.

If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in cpususpendenter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel.

Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console.

To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online.

From cited commit [2]

Extend to check for CONFIGKASANSTACK

[1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIGKASANSTACK")

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

mm/slab: make free(kfree) accept error pointers

Currently, if an automatically freed allocation is an error pointer that will lead to a crash. An example of this is in wm831xgpiodbgshow().

171 char label free(kfree) = gpiochipduplinelabel(chip, i); 172 if (ISERR(label)) { 173 deverr(wm831x->dev, "Failed to duplicate label\n"); 174 continue; 175 }

The auto clean up function should check for error pointers as well, otherwise we're going to keep hitting issues like this.

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

Bluetooth: qca: add missing firmware sanity checks

Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.

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

uiohvgeneric: Don't free decrypted memory

In CoCo VMs it is possible for the untrusted host to cause setmemoryencrypted() or setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

The VMBus device UIO driver could free decrypted/shared pages if setmemorydecrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.

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

nsh: Restore skb->{protocol,data,macheader} for outer header in nshgsosegment().

syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIONETHDRGSOUDP layering the following protocols:

ETHP8021AD + ETHPNSH + ETHPIPV6 + IPPROTOUDP

NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nshgsosegment(), calls skbmacgsosegment() to invoke inner protocol GSO handlers.

nshgsosegment() does the following for the original skb before calling skbmacgsosegment()

1. reset skb->networkheader 2. save the original skb->{macheaeder,maclen} in a local variable 3. pull the NSH header 4. resets skb->macheader 5. set up skb->maclen and skb->protocol for the inner protocol.

and does the following for the segmented skb

6. set ntohs(ETHPNSH) to skb->protocol 7. push the NSH header 8. restore skb->macheader 9. set skb->macheader + maclen to skb->networkheader 10. restore skb->maclen

There are two problems in 6-7 and 8-9.

(a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETHP8021AD in this case) is stripped when skb is sent out of netdev.

Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skbpull() in the first nshgsosegment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nshgsosegment().

(b) While restoring skb->{macheader,networkheader} in 8 & 9, nshgsosegment() does not assume that the data in the linear buffer is shifted.

However, udp6ufofragment() could shift the data and change skb->macheader accordingly as demonstrated by syzbot.

If this happens, even the restored skb->macheader points to the middle of the outer header.

It seems nshgsosegment() has never worked with outer headers so far.

At the end of nshgsosegment(), the outer header must be restored for the segmented skb, instead of the NSH header.

To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,macheader,protocol} properly.

[0]: BUG: KMSAN: uninit-value in ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:524 [inline] BUG: KMSAN: uninit-value in ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] BUG: KMSAN: uninit-value in ipvlanqueuexmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlancore.c:668 ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:524 [inline] ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] ipvlanqueuexmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlancore.c:668 ipvlanstartxmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlanmain.c:222 netdevstartxmit include/linux/netdevice.h:4989 [inline] netdevstartxmit include/linux/netdevice.h:5003 [inline] xmitone net/core/dev.c:3547 [inline] devhardstartxmit+0x244/0xa10 net/core/dev.c:3563 devqueuexmit+0x33ed/0x51c0 net/core/dev.c:4351 devqueuexmit include/linux/netdevice.h:3171 [inline] packetxmit+0x9c/0x6b0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3081 [inline] packetsendmsg+0x8aef/0x9f10 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendto+0x735/0xa10 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: slabpostallochook mm/slub.c:3819 [inline] slaballocnode mm/slub.c:3860 [inline] dokmallocnode mm/slub.c:3980 [inline] kmallocnodetrackcaller+0x705/0x1000 mm/slub.c:4001 kmallocreserve+0x249/0x4a0 net/core/skbuff.c:582 ---truncated---

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

pinctrl: core: delete incorrect free in pinctrlenable()

The "pctldev" struct is allocated in devmpinctrlregisterandinit(). It's a devm managed pointer that is freed by devmpinctrldevrelease(), so freeing it in pinctrlenable() will lead to a double free.

The devmpinctrldevrelease() function frees the pindescs and destroys the mutex as well.

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:

ice: ensure the copied buf is NUL terminated

Currently, we allocate a count-sized kernel buffer and copy count bytes 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.