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

Input: aiptek - properly check endpoint type

Syzbot reported warning in usbsubmiturb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint.

Fix it by replacing old desc.bNumEndpoints check with usbfindcommonendpoints() helper for finding endpoints

Fail log:

usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usbhubwq hubevent ... Call Trace: aiptekopen+0xd5/0x130 drivers/input/tablet/aiptek.c:830 inputopendevice+0x1bb/0x320 drivers/input/input.c:629 kbdconnect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593

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

Bluetooth: btintel: Fix null ptr deref in btintelreadversion

If hcicmdsynccomplete() is triggered and skb is NULL, then hdev->reqskb is NULL, which will cause this issue.

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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

net: atm: fix crash due to unvalidated vcc pointer in sigdsend()

Reproducer available at [1].

The ATM send path (sendmsg -> vccsendmsg -> sigdsend) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AFATMSVC, SOCKDGRAM, 0); ioctl(fd, ATMSIGDCTRL); // become ATM signaling daemon struct msghdr msg = { .msgiov = &iov, ... }; (unsigned long )(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigdenq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing findgetvcc() which validates the pointer by searching through vcchash (similar to how sigdclose() iterates over all VCCs), and acquires a reference via sockhold() if found.

Since struct atmvcc embeds struct sock as its first member, they share the same lifetime. Therefore using sockhold/sockput is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigdclose() which could mark the vcc with various flags (e.g., ATMVFRELEASED) after findgetvcc() returns. However, sockhold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

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

ACPI: LPIT: Avoid u32 multiplication overflow

In lpitupdateresidency() there is a possibility of overflow in multiplication, if tsckhz is large enough (> UINTMAX/1000).

Change multiplication to mulu32u32().

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

calipso: fix memory leak in netlblcalipsoaddpass()

If IPv6 support is disabled at boot (ipv6.disable=1), the calipsoinit() -> netlblcalipsoopsregister() function isn't called, and the netlblcalipsoopsget() function always returns NULL. In this case, the netlblcalipsoaddpass() function allocates memory for the doidef variable but doesn't free it with the calipsodoifree().

BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlblcalipsoaddpass net/netlabel/netlabelcalipso.c:76 [inline] [<...>] netlblcalipsoadd+0x22e/0x4f0 net/netlabel/netlabelcalipso.c:111 [<...>] genlfamilyrcvmsgdoit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genlfamilyrcvmsg net/netlink/genetlink.c:783 [inline] [<...>] genlrcvmsg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlinkrcvskb+0x14d/0x440 net/netlink/afnetlink.c:2515 [<...>] genlrcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlinkunicastkernel net/netlink/afnetlink.c:1313 [inline] [<...>] netlinkunicast+0x54b/0x800 net/netlink/afnetlink.c:1339 [<...>] netlinksendmsg+0x90a/0xdf0 net/netlink/afnetlink.c:1934 [<...>] socksendmsgnosec net/socket.c:651 [inline] [<...>] socksendmsg+0x157/0x190 net/socket.c:671 [<...>] syssendmsg+0x712/0x870 net/socket.c:2342 [<...>] syssendmsg+0xf8/0x170 net/socket.c:2396 [<...>] syssendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] dosyscall64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entrySYSCALL64afterhwframe+0x61/0xc6

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller

[PM: merged via the LSM tree at Jakub Kicinski request]

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

Bluetooth: l2cap: fix null-ptr-deref in l2capchantimeout

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051300-CVE-2024-27399-afa8@gregkh/T

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

wifi: ath11k: fix error path leaks in some WMI WOW calls

Fix two instances where we used to directly return the result of ath11kwmicmdsend(...). Because we did not check the return value, we also did not free the skb in the error path.

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

Input: elani2c - prevent division by zero and arithmetic underflow

The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for xtraces or ytraces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe.

Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1.

Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETPFWIDTHREDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios.

Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.

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

MIPS: DEC: Prevent initial console buffer from landing in XKPHYS

In 64-bit configurations calling the initial console output handler from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment and consequently so has been the buffer allocated there that is used as the argument corresponding to the %s' output conversion specifier for the firmware's printf() entry point.

This 64-bit address will then be truncated by 32-bit firmware, resulting in an attempt to access the wrong memory location, which in turn will cause all kinds of unpredictable behaviour, such as a kernel crash:

Console: colour dummy device 160x64 Calibrating delay loop... 49.36 BogoMIPS (lpj=192512) pidmax: default: 32768 minimum: 301 CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800 Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121 $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0 $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073 $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473 $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000 $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240 $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b $24 : ffffffffffffffbf 000000000203bd00 $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800 Hi : 0000000000000000 Lo : 0000000000000aa8 epc : ffffffffbfc08364 0xffffffffbfc08364 ra : ffffffffbfc08800 0xffffffffbfc08800 Status: 140120e2 KX SX UX KERNEL EXL Cause : 00000008 (ExcCode 02) BadVA : 000000000203bd00 PrId : 00000430 (R4000SC) Modules linked in: Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=0000000000000000) Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38 0000000000000000 000000000203bd00 0000000000000000 0000000000000000 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000 ... Call Trace:

Code: a082ffff 03e00008 00601021 <80820000> 00001821 10400005 24840001 80820000 24630001

---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt

KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8) >>

In this case the pointer in $4 was truncated from 0x980000000203bd00 to 0x000000000203bd00.

This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started.

Fix the issue by making the buffer static and initdata, and therefore placed in the CKSEG0 32-bit compatibility segment, observing that the console output handler is called with the console lock held, implying no need for this code to be reentrant. Add an assertion to verify the buffer actually has been placed in a compatibility segment.

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

irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove

The driver allocates domain generic chips using irqallocdomaingenericchips() during probe and sets up chained handlers using irqsetchainedhandleranddata(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed.

The generic chips remain on the global gclist and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash.

The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory.

Fix these issues by:

- Setting IRQDOMAINFLAGDESTROYGC flag in domain->flags, so the core code automatically removes generic chips when irqdomainremove() is called

- Clearing all chained handlers with NULL in pdcintcremove()

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

fbdev: Fix fbnewmodelist to prevent null-ptr-deref in fbvideomodetovar

info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. vartodisplay() relies on this and treats a failed fbmatchmode() as "This should not happen". fbsetvar() keeps it true by adding the mode to the list on every change, and doregisterframebuffer() does the same at registration.

storemodes() replaces the modelist from userspace. fbnewmodelist() validates the new modes but does not check that info->var still has a match. It relies on fbconnewmodelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list.

A later console takeover runs vartodisplay(), where fbmatchmode() returns NULL and leaves fbdisplay[i].mode NULL. fbconswitch() passes it to displaytovar(), and fbvideomodetovar() dereferences the NULL mode.

Keep the current mode in the list in fbnewmodelist(), the same way fbsetvar() does.

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

media: vidtv: fix NULL pointer dereference in vidtvmuxpushsi

syzbot reported a general protection fault in vidtvpsitspsiwriteinto [1].

vidtvmuxgetpidctx() can return NULL, but vidtvmuxpushsi() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address.

The root cause is that vidtvmuxpidctxinit() does not check the return value of vidtvmuxcreatepidctxonce() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtvmuxpushsi() call then gets NULL from vidtvmuxgetpidctx() and crashes.

Fix both the root cause (add error check in vidtvmuxpidctxinit for PMT PIDs) and add defensive NULL checks in vidtvmuxpushsi for all vidtvmuxgetpidctx() calls.

[1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtvmuxtick RIP: 0010:vidtvpsitspsiwriteinto+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtvpsi.c:197 Call Trace: <TASK> vidtvpsitableheaderwriteinto drivers/media/test-drivers/vidtv/vidtvpsi.c:799 [inline] vidtvpsipmtwriteinto+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtvpsi.c:1231 vidtvmuxpushsi+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtvmux.c:196 vidtvmuxtick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtvmux.c:408

agp/amd64: Fix broken error propagation in agpamd64probe()

drm/amdgpu: Fix possible NULL dereference in amdgpurasqueryerrorstatushelper()

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

ceph: fix deadlock or deadcode of misusing dget()

The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first.

But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it.

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

drm/amd: fix potential memory leak

This patch fix potential memory leak (clksrc) when function run into last return NULL.

s/free/kfree/ - Alex

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

drm/amd/display: Fix potential null-deref in dmresume

[Why] Fixing smatch error: dmresume() error: we previously assumed 'aconnector->dclink' could be null

[How] Check if dclink null at the beginning of the loop, so further checks can be dropped.

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

orangefs: Fix kmemleak in orangefs{kernel,client}debuginit()

When insert and remove the orangefs module, there are memory leaked as below:

unreferenced object 0xffff88816b0cc000 (size 2048): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): 6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000005b405fee>] orangefsdebugfsinit.cold+0xaf/0x17f [<00000000e5a0085b>] 0xffffffffa02780f9 [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

Use the golbal variable as the buffer rather than dynamic allocate to slove the problem.

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

f2fs: fix to do sanity check on destination blkaddr during recovery

As Wenqing Liu reported in bugzilla:

https://bugzilla.kernel.org/showbug.cgi?id=216456

loop5: detected capacity change from 0 to 131072 F2FS-fs (loop5): recoverinode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recoverdata: ino = 6 (isize: recover) err = 0 F2FS-fs (loop5): recoverinode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recoverdata: ino = 6 (isize: recover) err = 0 F2FS-fs (loop5): recoverinode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recoverdata: ino = 6 (isize: recover) err = 0 F2FS-fs (loop5): Bitmap was wrongly set, blk:5634 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198 RIP: 0010:updatesitentry+0xa55/0x10b0 [f2fs] Call Trace: <TASK> f2fsdoreplaceblock+0xa98/0x1890 [f2fs] f2fsreplaceblock+0xeb/0x180 [f2fs] recoverdata+0x1a69/0x6ae0 [f2fs] f2fsrecoverfsyncdata+0x120d/0x1fc0 [f2fs] f2fsfillsuper+0x4665/0x61e0 [f2fs] mountbdev+0x2cf/0x3b0 legacygettree+0xed/0x1d0 vfsgettree+0x81/0x2b0 pathmount+0x47e/0x19d0 domount+0xce/0xf0 x64sysmount+0x12c/0x1a0 dosyscall64+0x38/0x90 entrySYSCALL64afterhwframe+0x63/0xcd

If we enable CONFIGF2FSCHECKFS config, it will trigger a kernel panic instead of warning.

The root cause is: in fuzzed image, SIT table is inconsistent with inode mapping table, result in triggering such warning during SIT table update.

This patch introduces a new flag DATAGENERICENHANCEUPDATE, w/ this flag, data block recovery flow can check destination blkaddr's validation in SIT table, and skip f2fsreplaceblock() to avoid inconsistent status.

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

arm64: fix oops in concurrently setting insnemulation sysctls

emulationprochandler() changes table->data for procdointvecminmax and can generate the following Oops if called concurrently with itself:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | updateinsnemulationmode+0xc0/0x148 | emulationprochandler+0x64/0xb8 | procsyscallhandler+0x9c/0xf8 | procsyswrite+0x18/0x20 | vfswrite+0x20/0x48 | vfswrite+0xe4/0x1d0 | ksyswrite+0x70/0xf8 | arm64syswrite+0x20/0x28 | el0svccommon.constprop.0+0x7c/0x1c0 | el0svchandler+0x2c/0xa0 | el0svc+0x8/0x200

To fix this issue, keep the table->data as &insn->currentmode and use containerof() to retrieve the insn pointer. Another mutex is used to protect against the currentmode update but not for retrieving insnemulation as table->data is no longer changing.

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

f2fs: fix to avoid use f2fsbugon() in f2fsnewnodepage()

As Dipanjan Das <mail.dipanjan.das@gmail.com> reported, syzkaller found a f2fs bug as below:

RIP: 0010:f2fsnewnodepage+0x19ac/0x1fc0 fs/f2fs/node.c:1295 Call Trace: writeallxattrs fs/f2fs/xattr.c:487 [inline] f2fssetxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743 f2fssetxattr+0x233/0xab0 fs/f2fs/xattr.c:790 f2fsxattrgenericset+0x133/0x170 fs/f2fs/xattr.c:86 vfssetxattr+0x115/0x180 fs/xattr.c:182 vfssetxattrnoperm+0x125/0x5f0 fs/xattr.c:216 vfssetxattrlocked+0x1cf/0x260 fs/xattr.c:277 vfssetxattr+0x13f/0x330 fs/xattr.c:303 setxattr+0x146/0x160 fs/xattr.c:611 pathsetxattr+0x1a7/0x1d0 fs/xattr.c:630 dosyslsetxattr fs/xattr.c:653 [inline] sesyslsetxattr fs/xattr.c:649 [inline] x64syslsetxattr+0xbd/0x150 fs/xattr.c:649 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x46/0xb0

NAT entry and nat bitmap can be inconsistent, e.g. one nid is free in nat bitmap, and blkaddr in its NAT entry is not NULLADDR, it may trigger BUGON() in f2fsnewnodepage(), fix it.

btrfs: zoned: clone zoned device info when cloning a device

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

drm/amd/pm: add missing ->finimicrocode interface for Sienna Cichlid

To avoid any potential memory leak.

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

udmabuf: Set the DMA mask for the udmabuf device (v2)

If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here:

WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 dmamapsgattrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dmamapsgattrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dmamapsgtable+0x70/0xf0 kernel/dma/mapping.c:264 getsgtable.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begincpuudmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dmabufbegincpuaccess+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dmabufioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:874 [inline] sesysioctl fs/ioctl.c:860 [inline] x64sysioctl+0x193/0x200 fs/ioctl.c:860 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>

v2: Dont't forget to deregister if DMA mask setup fails.

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

pinctrl: aspeed: Fix potential NULL dereference in aspeedpinmuxsetmux()

pdesc could be null but still dereference pdesc->name and it will lead to a null pointer access. So we move a null check before dereference.

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

media: venus: hfi: avoid null dereference in deinit

If venusprobe fails at pmruntimeputsync the error handling first calls hfidestroy and afterwards hficoredeinit. As hfidestroy sets core->ops to NULL, hficoredeinit cannot call the coredeinit function anymore.

Avoid this null pointer derefence by skipping the call when necessary.

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

arm64: compat: Do not treat syscall number as ESRELx for a bad syscall

If a compat process tries to execute an unknown system call above the ARMNRCOMPATEND number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compatarmsyscall() -> arm64notifydie() -> arm64forcesigfault() -> arm64showsignal().

arm64showsignal() interprets a non-zero value for current->thread.faultcode as an exception syndrome and displays the message associated with the ESRELx.EC field (bits 31:26). current->thread.faultcode is set in compatarmsyscall() -> arm64notifydie() with the bad syscall number instead of a valid ESRELx value. This means that the ESRELx.EC field has the value that the user set for the syscall number and the kernel can end up printing bogus exception messages. For example, for the syscall number 0x68000000, which evaluates to ESRELx.EC value of 0x1A (ESRELxECFPAC) the kernel prints this error:

[ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000] [ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79 [ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT) [..]

which is misleading, as the bad compat syscall has nothing to do with pointer authentication.

Stop arm64showsignal() from printing exception syndrome information by having compatarmsyscall() set the ESRELx value to 0, as it has no meaning for an invalid system call number. The example above now becomes:

[ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000] [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80 [ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT) [..]

which although shows less information because the syscall number, wrongfully advertised as the ESR value, is missing, it is better than showing plainly wrong information. The syscall number can be easily obtained with strace.

A 32-bit value above or equal to 0x80000000 is interpreted as a negative integer in compatarmsyscal() and the condition scno < ARMNRCOMPATEND evaluates to true; the syscall will exit to userspace in this case with the ENOSYS error code instead of arm64notifydie() being called.

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

ath11k: disable spectral scan during spectral deinit

When ath11k modules are removed using rmmod with spectral scan enabled, crash is observed. Different crash trace is observed for each crash.

Send spectral scan disable WMI command to firmware before cleaning the spectral dbring in the spectraldeinit API to avoid this crash.

call trace from one of the crash observed: [ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 1252.882722] pgd = 0f42e886 [ 1252.890955] [00000008] pgd=00000000 [ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0 [ 1253.115261] Hardware name: Generic DT based system [ 1253.121149] PC is at ath11kspectralprocessdata+0x434/0x574 [ath11k] [ 1253.125940] LR is at 0x88e31017 [ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193 [ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000 [ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080 [ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000 [ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001 [ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC32 ISA ARM Segment user [ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055 [ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141) [ 1253.458055] [<7f9387b8>] (ath11kspectralprocessdata [ath11k]) from [<7f917fdc>] (ath11kdbringbufferreleaseevent+0x214/0x2e4 [ath11k]) [ 1253.466139] [<7f917fdc>] (ath11kdbringbufferreleaseevent [ath11k]) from [<7f8ea3c4>] (ath11kwmitlvoprx+0x1840/0x29cc [ath11k]) [ 1253.478807] [<7f8ea3c4>] (ath11kwmitlvoprx [ath11k]) from [<7f8fe868>] (ath11khtcrxcompletionhandler+0x180/0x4e0 [ath11k]) [ 1253.490699] [<7f8fe868>] (ath11khtcrxcompletionhandler [ath11k]) from [<7f91308c>] (ath11kceperengineservice+0x2c4/0x3b4 [ath11k]) [ 1253.502386] [<7f91308c>] (ath11kceperengineservice [ath11k]) from [<7f9a4198>] (ath11kpcicetasklet+0x28/0x80 [ath11kpci]) [ 1253.514811] [<7f9a4198>] (ath11kpcicetasklet [ath11kpci]) from [<8032227c>] (taskletactioncommon.constprop.2+0x64/0xe8) [ 1253.526476] [<8032227c>] (taskletactioncommon.constprop.2) from [<803021e8>] (dosoftirq+0x130/0x2d0) [ 1253.537756] [<803021e8>] (dosoftirq) from [<80322610>] (irqexit+0xcc/0xe8) [ 1253.547304] [<80322610>] (irqexit) from [<8036a4a4>] (handledomainirq+0x60/0xb4) [ 1253.554428] [<8036a4a4>] (handledomainirq) from [<805eb348>] (gichandleirq+0x4c/0x90) [ 1253.562321] [<805eb348>] (gichandleirq) from [<80301a78>] (irqsvc+0x58/0x8c)

Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPLSILICONZ-1

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

f2fs: fix to avoid f2fsbugon() in decvalidnodecount()

As Yanming reported in bugzilla:

https://bugzilla.kernel.org/showbug.cgi?id=215897

I have encountered a bug in F2FS file system in kernel v5.17.

The kernel should enable CONFIGKASAN=y and CONFIGKASANINLINE=y. You can reproduce the bug by running the following commands:

The kernel message is shown below:

kernel BUG at fs/f2fs/f2fs.h:2511! Call Trace: f2fsremoveinodepage+0x2a2/0x830 f2fsevictinode+0x9b7/0x1510 evict+0x282/0x4e0 dounlinkat+0x33a/0x540 x64sysunlinkat+0x8e/0xd0 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x44/0xae

The root cause is: .totalvalidblockcount or .totalvalidnodecount could fuzzed to zero, then once decvalidnodecount() was called, it will cause BUGON(), this patch fixes to print warning info and set SBINEEDFSCK into CP instead of panic.