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:

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:

nbd: fix incomplete validation of ioctl arg

We tested and found an alarm caused by nbdioctl arg without verification. The UBSAN warning calltrace like below:

UBSAN: Undefined behaviour in fs/buffer.c:1709:35 signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long long int' CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1 Hardware name: linux,dummy-virt (DT) Call trace: dumpbacktrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 showstack+0x28/0x38 arch/arm64/kernel/traps.c:158 dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x170/0x1dc lib/dumpstack.c:118 ubsanepilogue+0x18/0xb4 lib/ubsan.c:161 handleoverflow+0x188/0x1dc lib/ubsan.c:192 ubsanhandlesuboverflow+0x34/0x44 lib/ubsan.c:206 blockwritefullpage+0x94c/0xa20 fs/buffer.c:1709 blockwritefullpage+0x1f0/0x280 fs/buffer.c:2934 blkdevwritepage+0x34/0x40 fs/blockdev.c:607 writepage+0x68/0xe8 mm/page-writeback.c:2305 writecachepages+0x44c/0xc70 mm/page-writeback.c:2240 genericwritepages+0xdc/0x148 mm/page-writeback.c:2329 blkdevwritepages+0x2c/0x38 fs/blockdev.c:2114 dowritepages+0xd4/0x250 mm/page-writeback.c:2344

The reason for triggering this warning is blockwritefullpage() - isizeread(inode) - 1 overflow. inode-isize is assigned in nbdioctl() - nbdsetsize() - bytesize. We think it is necessary to limit the size of arg to prevent errors.

Moreover, nbdioctl() - nbdaddsocket(), arg will be cast to int. Assuming the value of arg is 0x80000000000000001) (on a 64-bit machine), it will become 1 after the coercion, which will return unexpected results.

Fix it by adding checks to prevent passing in too large numbers.

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:

net/mlx5e: Prevent deadlock while disabling aRFS

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27014-d2dc@gregkh/T

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

net: veth: clear GRO when clearing XDP even when down

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040404-CVE-2024-26803-9985@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:

xfs: fail recovery on a committed log item with no regions

If the first op of a transaction is a bare transaction header (len == sizeof(struct xfstransheader)), xlogrecoveraddtotrans() adds an item but no region, leaving it on ritemq with ricnt == 0 and ribuf == NULL.

The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser.

xlogrecoverreordertrans() calls ITEMTYPE() on the item, which reads (unsigned short )item->ribuf[0].iovbase and faults on the NULL ribuf. Reject it there, before the commit handlers that also read ribuf[0].

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlogrecoverreordertrans (fs/xfs/xfslogrecover.c:1836) xlogrecovercommittrans (fs/xfs/xfslogrecover.c:2043) xlogrecoverprocessdata (fs/xfs/xfslogrecover.c:2501) xlogdorecoverypass (fs/xfs/xfslogrecover.c:3244) xlogrecover (fs/xfs/xfslogrecover.c:3493) xfslogmount (fs/xfs/xfslog.c:618) xfsmountfs (fs/xfs/xfsmount.c:1034) xfsfsfillsuper (fs/xfs/xfssuper.c:1938) vfsgettree (fs/super.c:1695) pathmount (fs/namespace.c:4161) x64sysmount (fs/namespace.c:4367)

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:

ksmbd: call rcubarrier() in ksmbdserverexit()

racy issue is triggered the bug by racing between closing a connection and rmmod. In ksmbd, rcubarrier() is not called at module unload time, so nothing prevents ksmbd from getting unloaded while it still has RCU callbacks pending. It leads to trigger unintended execution of kernel code locally and use to defeat protections such as Kernel Lockdown

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

fs/ntfs3: Fix memory leak on ntfsfillsuper() error path

syzbot reported kmemleak as below:

BUG: memory leak unreferenced object 0xffff8880122f1540 (size 32): comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ed ff ed ff 00 00 00 00 ................ backtrace: [<ffffffff81b16052>] ntfsinitfscontext+0x22/0x1c0 [<ffffffff8164aaa7>] allocfscontext+0x217/0x430 [<ffffffff81626dd4>] pathmount+0x704/0x1080 [<ffffffff81627e7c>] x64sysmount+0x18c/0x1d0 [<ffffffff84593e14>] dosyscall64+0x34/0xb0 [<ffffffff84600087>] entrySYSCALL64afterhwframe+0x63/0xcd

This patch fixes this issue by freeing mount options on error path of ntfsfillsuper().

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:

crypto: hisilicon/hpre - fix resource leak in remove process

In hpreremove(), when the disable operation of qm sriov failed, the following logic should continue to be executed to release the remaining resources that have been allocated, instead of returning directly, otherwise there will be resource leakage.

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

fs/ntfs3: Add null pointer check to attrloadrunsvcn

Some metadata files are handled before MFT. This adds a null pointer check for some corner cases that could lead to NPD while reading these metadata files for a malformed NTFS image.

[ 240.190827] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 240.191583] #PF: supervisor read access in kernel mode [ 240.191956] #PF: errorcode(0x0000) - not-present page [ 240.192391] PGD 0 P4D 0 [ 240.192897] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 240.193805] CPU: 0 PID: 242 Comm: mount Tainted: G B 5.19.0+ #17 [ 240.194477] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 240.195152] RIP: 0010:nifindattr+0xae/0x300 [ 240.195679] Code: c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 e2 d9f [ 240.196642] RSP: 0018:ffff88800812f690 EFLAGS: 00000286 [ 240.197019] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a [ 240.197523] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60 [ 240.197877] RBP: ffff88800812f738 R08: 0000000000000001 R09: fffffbfff11d2bed [ 240.198292] R10: ffffffff88e95f67 R11: fffffbfff11d2bec R12: 0000000000000000 [ 240.198647] R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000000 [ 240.199410] FS: 00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 240.199895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 240.200314] CR2: 0000000000000158 CR3: 0000000004d32000 CR4: 00000000000006f0 [ 240.200839] Call Trace: [ 240.201104] <TASK> [ 240.201502] ? niloadmi+0x80/0x80 [ 240.202297] ? slaballoc+0x465/0x830 [ 240.202614] attrloadrunsvcn+0x8c/0x1a0 [ 240.202886] ? kasanslaballoc+0x32/0x90 [ 240.203157] ? attrdatawriteresident+0x250/0x250 [ 240.203543] miread+0x133/0x2c0 [ 240.203785] miget+0x70/0x140 [ 240.204012] niloadmiex+0xfa/0x190 [ 240.204346] ? nistd5+0x90/0x90 [ 240.204588] ? kasankmalloc+0x88/0xb0 [ 240.204859] nienumattrex+0xf1/0x1c0 [ 240.205107] ? nifnametype.part.0+0xd0/0xd0 [ 240.205600] ? ntfsloadattrlist+0xbe/0x300 [ 240.205864] ? ntfscmpnamescpu+0x125/0x180 [ 240.206157] ntfsiget5+0x56c/0x1870 [ 240.206510] ? ntfsgetblockbmap+0x70/0x70 [ 240.206776] ? kasankmalloc+0x88/0xb0 [ 240.207030] ? setblocksize+0x95/0x150 [ 240.207545] ntfsfillsuper+0xb8f/0x1e20 [ 240.207839] ? putntfs+0x1d0/0x1d0 [ 240.208069] ? vsprintf+0x20/0x20 [ 240.208467] ? mutexunlock+0x81/0xd0 [ 240.208846] ? setblocksize+0x95/0x150 [ 240.209221] gettreebdev+0x232/0x370 [ 240.209804] ? putntfs+0x1d0/0x1d0 [ 240.210519] ntfsfsgettree+0x15/0x20 [ 240.210991] vfsgettree+0x4c/0x130 [ 240.211455] pathmount+0x645/0xfd0 [ 240.211806] ? putname+0x80/0xa0 [ 240.212112] ? finishautomount+0x2e0/0x2e0 [ 240.212559] ? kmemcachefree+0x110/0x390 [ 240.212906] ? putname+0x80/0xa0 [ 240.213329] domount+0xd6/0xf0 [ 240.213829] ? pathmount+0xfd0/0xfd0 [ 240.214246] ? kasancheckwrite+0x14/0x20 [ 240.214774] x64sysmount+0xca/0x110 [ 240.215080] dosyscall64+0x3b/0x90 [ 240.215442] entrySYSCALL64afterhwframe+0x63/0xcd [ 240.215811] RIP: 0033:0x7f233b4e948a [ 240.216104] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 240.217615] RSP: 002b:00007fff02211ec8 EFLAGS: 00000202 ORIGRAX: 00000000000000a5 [ 240.218718] RAX: ffffffffffffffda RBX: 0000561cdc35b060 RCX: 00007f233b4e948a [ 240.219556] RDX: 0000561cdc35b260 RSI: 0000561cdc35b2e0 RDI: 0000561cdc363af0 [ 240.219975] RBP: 0000000000000000 R08: 0000561cdc35b280 R09: 0000000000000020 [ 240.220403] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000561cdc363af0 [ 240.220803] R13: 000 ---truncated---

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:

fs/ntfs3: Validate BOOT recordsize

When the NTFS BOOT recordsize field < 0, it represents a shift value. However, there is no sanity check on the shift result and the sbi->recordbits calculation through blksizebits() assumes the size always > 256, which could lead to NPD while mounting a malformed NTFS image.

[ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 318.675682] #PF: supervisor read access in kernel mode [ 318.675869] #PF: errorcode(0x0000) - not-present page [ 318.676246] PGD 0 P4D 0 [ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5 [ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 318.678136] RIP: 0010:nifindattr+0x2d/0x1c0 [ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0 [ 318.685623] Call Trace: [ 318.686607] <TASK> [ 318.686872] ? ntfsallocinode+0x1a/0x60 [ 318.687235] attrloadrunsvcn+0x2b/0xa0 [ 318.687468] miread+0xbb/0x250 [ 318.687576] ntfsiget5+0x114/0xd90 [ 318.687750] ntfsfillsuper+0x588/0x11b0 [ 318.687953] ? putntfs+0x130/0x130 [ 318.688065] ? snprintf+0x49/0x70 [ 318.688164] ? putntfs+0x130/0x130 [ 318.688256] gettreebdev+0x16a/0x260 [ 318.688407] vfsgettree+0x20/0xb0 [ 318.688519] pathmount+0x2dc/0x9b0 [ 318.688877] domount+0x74/0x90 [ 318.689142] x64sysmount+0x89/0xd0 [ 318.689636] dosyscall64+0x3b/0x90 [ 318.689998] entrySYSCALL64afterhwframe+0x63/0xcd [ 318.690318] RIP: 0033:0x7fd9e133c48a [ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIGRAX: 00000000000000a5 [ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a [ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0 [ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020 [ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0 [ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff [ 318.693007] </TASK> [ 318.693271] Modules linked in: [ 318.693614] CR2: 0000000000000158 [ 318.694446] ---[ end trace 0000000000000000 ]--- [ 318.694779] RIP: 0010:nifindattr+0x2d/0x1c0 [ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ ---truncated---

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.

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.