Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: split initial and dynamic conditions for extent_cache<br /> <br /> Let&amp;#39;s allocate the extent_cache tree without dynamic conditions to avoid a<br /> missing condition causing a panic as below.<br /> <br /> # create a file w/ a compressed flag<br /> # disable the compression<br /> # panic while updating extent_cache<br /> <br /> F2FS-fs (dm-64): Swapfile: last extent is not aligned to section<br /> F2FS-fs (dm-64): Swapfile (3) is not align to section: 1) creat(), 2) ioctl(F2FS_IOC_SET_PIN_FILE), 3) fallocate(2097152 * N)<br /> Adding 124996k swap on ./swap-file. Priority:0 extents:2 across:17179494468k<br /> ==================================================================<br /> BUG: KASAN: null-ptr-deref in instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline]<br /> BUG: KASAN: null-ptr-deref in atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline]<br /> BUG: KASAN: null-ptr-deref in queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline]<br /> BUG: KASAN: null-ptr-deref in __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline]<br /> BUG: KASAN: null-ptr-deref in _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295<br /> Write of size 4 at addr 0000000000000030 by task syz-executor154/3327<br /> <br /> CPU: 0 PID: 3327 Comm: syz-executor154 Tainted: G O 5.10.185 #1<br /> Hardware name: emulation qemu-x86/qemu-x86, BIOS 2023.01-21885-gb3cc1cd24d 01/01/2023<br /> Call Trace:<br /> __dump_stack out/common/lib/dump_stack.c:77 [inline]<br /> dump_stack_lvl+0x17e/0x1c4 out/common/lib/dump_stack.c:118<br /> __kasan_report+0x16c/0x260 out/common/mm/kasan/report.c:415<br /> kasan_report+0x51/0x70 out/common/mm/kasan/report.c:428<br /> kasan_check_range+0x2f3/0x340 out/common/mm/kasan/generic.c:186<br /> __kasan_check_write+0x14/0x20 out/common/mm/kasan/shadow.c:37<br /> instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline]<br /> atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline]<br /> queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline]<br /> __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline]<br /> _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295<br /> __drop_extent_tree+0xdf/0x2f0 out/common/fs/f2fs/extent_cache.c:1155<br /> f2fs_drop_extent_tree+0x17/0x30 out/common/fs/f2fs/extent_cache.c:1172<br /> f2fs_insert_range out/common/fs/f2fs/file.c:1600 [inline]<br /> f2fs_fallocate+0x19fd/0x1f40 out/common/fs/f2fs/file.c:1764<br /> vfs_fallocate+0x514/0x9b0 out/common/fs/open.c:310<br /> ksys_fallocate out/common/fs/open.c:333 [inline]<br /> __do_sys_fallocate out/common/fs/open.c:341 [inline]<br /> __se_sys_fallocate out/common/fs/open.c:339 [inline]<br /> __x64_sys_fallocate+0xb8/0x100 out/common/fs/open.c:339<br /> do_syscall_64+0x35/0x50 out/common/arch/x86/entry/common.c:46

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/port: Fix delete_endpoint() vs parent unregistration race<br /> <br /> The CXL subsystem, at cxl_mem -&gt;probe() time, establishes a lineage of<br /> ports (struct cxl_port objects) between an endpoint and the root of a<br /> CXL topology. Each port including the endpoint port is attached to the<br /> cxl_port driver.<br /> <br /> Given that setup, it follows that when either any port in that lineage<br /> goes through a cxl_port -&gt;remove() event, or the memdev goes through a<br /> cxl_mem -&gt;remove() event. The hierarchy below the removed port, or the<br /> entire hierarchy if the memdev is removed needs to come down.<br /> <br /> The delete_endpoint() callback is careful to check whether it is being<br /> called to tear down the hierarchy, or if it is only being called to<br /> teardown the memdev because an ancestor port is going through<br /> -&gt;remove().<br /> <br /> That care needs to take the device_lock() of the endpoint&amp;#39;s parent.<br /> Which requires 2 bugs to be fixed:<br /> <br /> 1/ A reference on the parent is needed to prevent use-after-free<br /> scenarios like this signature:<br /> <br /> BUG: spinlock bad magic on CPU#0, kworker/u56:0/11<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc38 05/24/2023<br /> Workqueue: cxl_port detach_memdev [cxl_core]<br /> RIP: 0010:spin_bug+0x65/0xa0<br /> Call Trace:<br /> do_raw_spin_lock+0x69/0xa0<br /> __mutex_lock+0x695/0xb80<br /> delete_endpoint+0xad/0x150 [cxl_core]<br /> devres_release_all+0xb8/0x110<br /> device_unbind_cleanup+0xe/0x70<br /> device_release_driver_internal+0x1d2/0x210<br /> detach_memdev+0x15/0x20 [cxl_core]<br /> process_one_work+0x1e3/0x4c0<br /> worker_thread+0x1dd/0x3d0<br /> <br /> 2/ In the case of RCH topologies, the parent device that needs to be<br /> locked is not always @port-&gt;dev as returned by cxl_mem_find_port(), use<br /> endpoint-&gt;dev.parent instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: fix use-after-free in unix_stream_read_actor()<br /> <br /> syzbot reported the following crash [1]<br /> <br /> After releasing unix socket lock, u-&gt;oob_skb can be changed<br /> by another thread. We must temporarily increase skb refcount<br /> to make sure this other thread will not free the skb under us.<br /> <br /> [1]<br /> <br /> BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866<br /> Read of size 4 at addr ffff88801f3b9cc4 by task syz-executor107/5297<br /> <br /> CPU: 1 PID: 5297 Comm: syz-executor107 Not tainted 6.6.0-syzkaller-15910-gb8e3a87a627b #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:364 [inline]<br /> print_report+0xc4/0x620 mm/kasan/report.c:475<br /> kasan_report+0xda/0x110 mm/kasan/report.c:588<br /> unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866<br /> unix_stream_recv_urg net/unix/af_unix.c:2587 [inline]<br /> unix_stream_read_generic+0x19a5/0x2480 net/unix/af_unix.c:2666<br /> unix_stream_recvmsg+0x189/0x1b0 net/unix/af_unix.c:2903<br /> sock_recvmsg_nosec net/socket.c:1044 [inline]<br /> sock_recvmsg+0xe2/0x170 net/socket.c:1066<br /> ____sys_recvmsg+0x21f/0x5c0 net/socket.c:2803<br /> ___sys_recvmsg+0x115/0x1a0 net/socket.c:2845<br /> __sys_recvmsg+0x114/0x1e0 net/socket.c:2875<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> RIP: 0033:0x7fc67492c559<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fc6748ab228 EFLAGS: 00000246 ORIG_RAX: 000000000000002f<br /> RAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007fc67492c559<br /> RDX: 0000000040010083 RSI: 0000000020000140 RDI: 0000000000000004<br /> RBP: 00007fc6749b6348 R08: 00007fc6748ab6c0 R09: 00007fc6748ab6c0<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc6749b6340<br /> R13: 00007fc6749b634c R14: 00007ffe9fac52a0 R15: 00007ffe9fac5388<br /> <br /> <br /> Allocated by task 5295:<br /> kasan_save_stack+0x33/0x50 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:328<br /> kasan_slab_alloc include/linux/kasan.h:188 [inline]<br /> slab_post_alloc_hook mm/slab.h:763 [inline]<br /> slab_alloc_node mm/slub.c:3478 [inline]<br /> kmem_cache_alloc_node+0x180/0x3c0 mm/slub.c:3523<br /> __alloc_skb+0x287/0x330 net/core/skbuff.c:641<br /> alloc_skb include/linux/skbuff.h:1286 [inline]<br /> alloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331<br /> sock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780<br /> sock_alloc_send_skb include/net/sock.h:1884 [inline]<br /> queue_oob net/unix/af_unix.c:2147 [inline]<br /> unix_stream_sendmsg+0xb5f/0x10a0 net/unix/af_unix.c:2301<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0xd5/0x180 net/socket.c:745<br /> ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584<br /> ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638<br /> __sys_sendmsg+0x117/0x1e0 net/socket.c:2667<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Freed by task 5295:<br /> kasan_save_stack+0x33/0x50 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522<br /> ____kasan_slab_free mm/kasan/common.c:236 [inline]<br /> ____kasan_slab_free+0x15b/0x1b0 mm/kasan/common.c:200<br /> kasan_slab_free include/linux/kasan.h:164 [inline]<br /> slab_free_hook mm/slub.c:1800 [inline]<br /> slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826<br /> slab_free mm/slub.c:3809 [inline]<br /> kmem_cache_free+0xf8/0x340 mm/slub.c:3831<br /> kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:1015<br /> __kfree_skb net/core/skbuff.c:1073 [inline]<br /> consume_skb net/core/skbuff.c:1288 [inline]<br /> consume_skb+0xdf/0x170 net/core/skbuff.c:1282<br /> queue_oob net/unix/af_unix.c:2178 [inline]<br /> u<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer()<br /> <br /> When ddc_service_construct() is called, it explicitly checks both the<br /> link type and whether there is something on the link which will<br /> dictate whether the pin is marked as hw_supported.<br /> <br /> If the pin isn&amp;#39;t set or the link is not set (such as from<br /> unloading/reloading amdgpu in an IGT test) then fail the<br /> amdgpu_dm_i2c_xfer() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/dasd: protect device queue against concurrent access<br /> <br /> In dasd_profile_start() the amount of requests on the device queue are<br /> counted. The access to the device queue is unprotected against<br /> concurrent access. With a lot of parallel I/O, especially with alias<br /> devices enabled, the device queue can change while dasd_profile_start()<br /> is accessing the queue. In the worst case this leads to a kernel panic<br /> due to incorrect pointer accesses.<br /> <br /> Fix this by taking the device lock before accessing the queue and<br /> counting the requests. Additionally the check for a valid profile data<br /> pointer can be done earlier to avoid unnecessary locking in a hot path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix slab out of bounds write in smb_inherit_dacl()<br /> <br /> slab out-of-bounds write is caused by that offsets is bigger than pntsd<br /> allocation size. This patch add the check to validate 3 offsets using<br /> allocation size.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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:<br /> <br /> riscv: VMAP_STACK overflow detection thread-safe<br /> <br /> commit 31da94c25aea ("riscv: add VMAP_STACK overflow detection") added<br /> support for CONFIG_VMAP_STACK. If overflow is detected, CPU switches to<br /> `shadow_stack` temporarily before switching finally to per-cpu<br /> `overflow_stack`.<br /> <br /> If two CPUs/harts are racing and end up in over flowing kernel stack, one<br /> or both will end up corrupting each other state because `shadow_stack` is<br /> not per-cpu. This patch optimizes per-cpu overflow stack switch by<br /> directly picking per-cpu `overflow_stack` and gets rid of `shadow_stack`.<br /> <br /> Following are the changes in this patch<br /> <br /> - Defines an asm macro to obtain per-cpu symbols in destination<br /> register.<br /> - In entry.S, when overflow is detected, per-cpu overflow stack is<br /> located using per-cpu asm macro. Computing per-cpu symbol requires<br /> a temporary register. x31 is saved away into CSR_SCRATCH<br /> (CSR_SCRATCH is anyways zero since we&amp;#39;re in kernel).<br /> <br /> Please see Links for additional relevant disccussion and alternative<br /> solution.<br /> <br /> Tested by `echo EXHAUST_STACK &gt; /sys/kernel/debug/provoke-crash/DIRECT`<br /> Kernel crash log below<br /> <br /> Insufficient stack space to handle exception!/debug/provoke-crash/DIRECT<br /> Task stack: [0xff20000010a98000..0xff20000010a9c000]<br /> Overflow stack: [0xff600001f7d98370..0xff600001f7d99370]<br /> CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34<br /> Hardware name: riscv-virtio,qemu (DT)<br /> epc : __memset+0x60/0xfc<br /> ra : recursive_loop+0x48/0xc6 [lkdtm]<br /> epc : ffffffff808de0e4 ra : ffffffff0163a752 sp : ff20000010a97e80<br /> gp : ffffffff815c0330 tp : ff600000820ea280 t0 : ff20000010a97e88<br /> t1 : 000000000000002e t2 : 3233206874706564 s0 : ff20000010a982b0<br /> s1 : 0000000000000012 a0 : ff20000010a97e88 a1 : 0000000000000000<br /> a2 : 0000000000000400 a3 : ff20000010a98288 a4 : 0000000000000000<br /> a5 : 0000000000000000 a6 : fffffffffffe43f0 a7 : 00007fffffffffff<br /> s2 : ff20000010a97e88 s3 : ffffffff01644680 s4 : ff20000010a9be90<br /> s5 : ff600000842ba6c0 s6 : 00aaaaaac29e42b0 s7 : 00fffffff0aa3684<br /> s8 : 00aaaaaac2978040 s9 : 0000000000000065 s10: 00ffffff8a7cad10<br /> s11: 00ffffff8a76a4e0 t3 : ffffffff815dbaf4 t4 : ffffffff815dbaf4<br /> t5 : ffffffff815dbab8 t6 : ff20000010a9bb48<br /> status: 0000000200000120 badaddr: ff20000010a97e88 cause: 000000000000000f<br /> Kernel panic - not syncing: Kernel stack overflow<br /> CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34<br /> Hardware name: riscv-virtio,qemu (DT)<br /> Call Trace:<br /> [] dump_backtrace+0x30/0x38<br /> [] show_stack+0x40/0x4c<br /> [] dump_stack_lvl+0x44/0x5c<br /> [] dump_stack+0x18/0x20<br /> [] panic+0x126/0x2fe<br /> [] walk_stackframe+0x0/0xf0<br /> [] recursive_loop+0x48/0xc6 [lkdtm]<br /> SMP: stopping secondary CPUs<br /> ---[ end Kernel panic - not syncing: Kernel stack overflow ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-blk: fix implicit overflow on virtio_max_dma_size<br /> <br /> The following codes have an implicit conversion from size_t to u32:<br /> (u32)max_size = (size_t)virtio_max_dma_size(vdev);<br /> <br /> This may lead overflow, Ex (size_t)4G -&gt; (u32)0. Once<br /> virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX<br /> instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: mipi-i3c-hci: Fix a kernel panic for accessing DAT_data.<br /> <br /> The `i3c_master_bus_init` function may attach the I2C devices before the<br /> I3C bus initialization. In this flow, the DAT `alloc_entry`` will be used<br /> before the DAT `init`. Additionally, if the `i3c_master_bus_init` fails,<br /> the DAT `cleanup` will execute before the device is detached, which will<br /> execue DAT `free_entry` function. The above scenario can cause the driver<br /> to use DAT_data when it is NULL.