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:
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
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/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:
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.
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:
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:
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.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to clear dirty inode in f2fsevictinode()
As Yanming reported in bugzilla:
https://bugzilla.kernel.org/showbug.cgi?id=215904
The kernel message is shown below:
kernel BUG at fs/f2fs/inode.c:825! Call Trace: evict+0x282/0x4e0 dentrykill+0x2b2/0x4d0 shrinkdentrylist+0x17c/0x4f0 shrinkdcacheparent+0x143/0x1e0 doonetree+0x9/0x30 shrinkdcacheforumount+0x51/0x120 genericshutdownsuper+0x5c/0x3a0 killblocksuper+0x90/0xd0 killf2fssuper+0x225/0x310 deactivatelockedsuper+0x78/0xc0 cleanupmnt+0x2b7/0x480 taskworkrun+0xc8/0x150 exittousermodeprepare+0x14a/0x150 syscallexittousermode+0x1d/0x40 dosyscall64+0x48/0x90
The root cause is: inode node and dnode node share the same nid, so during f2fsevictinode(), dnode node truncation will invalidate its NAT entry, so when truncating inode node, it fails due to invalid NAT entry, result in inode is still marked as dirty, fix this issue by clearing dirty for inode and setting SBINEEDFSCK flag in filesystem.
output from dump.f2fs: [printnodeinfo: 354] Node ID [0xf:15] is inode inid[0] [0x f : 15]
In the Linux kernel, the following vulnerability has been resolved:
f2fs: remove WARNON in f2fsisvalidblkaddr
Syzbot triggers two WARNs in f2fsisvalidblkaddr and isbitmapvalid. For example, in f2fsisvalidblkaddr, if type is DATAGENERICENHANCE or DATAGENERICENHANCEREAD, it invokes WARNON if blkaddr is not in the right range. The call trace is as follows:
f2fsgetnodeinfo+0x45f/0x1070 readnodepage+0x577/0x1190 getnodepage.part.0+0x9e/0x10e0 getnodepage f2fsgetnodepage+0x109/0x180 doreadinode f2fsiget+0x2a5/0x58b0 f2fsfillsuper+0x3b39/0x7ca0
Fix these two WARNs by replacing WARNON with dumpstack.
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
In the Linux kernel, the following vulnerability has been resolved:
rpmsg: virtio: Free driveroverride when rpmsgremove()
Free driveroverride when rpmsgremove(), otherwise the following memory leak will occur:
unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsgns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] kmemcacheallocnode+0x1f8/0x320 [<000000002300d89b>] kmallocnodetrackcaller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driversetoverride+0xd0/0x164 [<000000003e9c4ea5>] rpmsgregisterdeviceoverride+0x98/0x170 [<000000001c0c89a8>] rpmsgnsregisterdevice+0x24/0x30 [<000000008bbf8fa2>] rpmsgprobe+0x2e0/0x3ec [<00000000e65a68df>] virtiodevprobe+0x1c0/0x280 [<00000000443331cc>] reallyprobe+0xbc/0x2dc [<00000000391064b1>] driverprobedevice+0x78/0xe0 [<00000000a41c9a5b>] driverprobedevice+0xd8/0x160 [<000000009c3bd5df>] deviceattachdriver+0xb8/0x140 [<0000000043cd7614>] busforeachdrv+0x7c/0xd4 [<000000003b929a36>] deviceattach+0x9c/0x19c [<00000000a94e0ba8>] deviceinitialprobe+0x14/0x20 [<000000003c999637>] busprobedevice+0xa0/0xac
In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: don't keep queue frozen during system suspend
Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending.
block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bioqueueenter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblkfreeze().
[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/
Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend.
In the Linux kernel, the following vulnerability has been resolved:
media: cx231xx: set devicecaps for 417
The videodevice for the MPEG encoder did not set devicecaps.
Add this, otherwise the video device can't be registered (you get a WARNON instead).
Not seen before since currently 417 support is disabled, but I found this while experimenting with it.
In the Linux kernel, the following vulnerability has been resolved:
netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets
When calling netlblconnsetattr(), addr->safamily is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipsosocksetattr() is triggered. Inside this function, the following code is executed:
skfullsock(sk) ? inetsk(sk)->pinet6 : NULL;
Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference.
This patch fixes the issue by checking if inet6sk(sk) returns a NULL pointer before accessing pinet6.
In the Linux kernel, the following vulnerability has been resolved:
thermal: int340x: Add NULL check for adev
Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL").
Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402thermalprobe().
Note, under the same directory, int3400thermalprobe() has such a check.
[ rjw: Subject edit, added Fixes: ]
clk: samsung: Fix UBSAN panic in samsungclkinit()
iio: light: veml6030: fix IIO device retrieval from embedded device
bpf: avoid holding freezemutex during mmap operation
In the Linux kernel, the following vulnerability has been resolved:
staging: iio: frequency: ad9832: fix division by zero in ad9832calcfreqreg()
In the ad9832writefrequency() function, clkgetrate() might return 0. This can lead to a division by zero when calling ad9832calcfreqreg(). The check if (fout > (clkgetrate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832writefrequency() function is called from ad9832write(), and fout is derived from a text buffer, which can contain any value.