Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open<br /> <br /> The mcp251x_hw_wake() function is called with the mpc_lock mutex held and<br /> disables the interrupt handler so that no interrupts can be processed while<br /> waking the device. If an interrupt has already occurred then waiting for<br /> the interrupt handler to complete will deadlock because it will be trying<br /> to acquire the same mutex.<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> mcp251x_open()<br /> mutex_lock(&amp;priv-&gt;mcp_lock)<br /> request_threaded_irq()<br /> <br /> mcp251x_can_ist()<br /> mutex_lock(&amp;priv-&gt;mcp_lock)<br /> mcp251x_hw_wake()<br /> disable_irq()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/tdx: Fix data leak in mmio_read()<br /> <br /> The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an<br /> address from the VMM.<br /> <br /> Sean noticed that mmio_read() unintentionally exposes the value of an<br /> initialized variable (val) on the stack to the VMM.<br /> <br /> This variable is only needed as an output value. It did not need to be<br /> passed to the VMM in the first place.<br /> <br /> Do not send the original value of *val to the VMM.<br /> <br /> [ dhansen: clarify what &amp;#39;val&amp;#39; is used for. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: unset the binding mark of a reused connection<br /> <br /> Steve French reported null pointer dereference error from sha256 lib.<br /> cifs.ko can send session setup requests on reused connection.<br /> If reused connection is used for binding session, conn-&gt;binding can<br /> still remain true and generate_preauth_hash() will not set<br /> sess-&gt;Preauth_HashValue and it will be NULL.<br /> It is used as a material to create an encryption key in<br /> ksmbd_gen_smb311_encryptionkey. -&gt;Preauth_HashValue cause null pointer<br /> dereference error from crypto_shash_update().<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 8 PID: 429254 Comm: kworker/8:39<br /> Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )<br /> Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]<br /> RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]<br /> <br /> ? show_regs+0x6d/0x80<br /> ? __die+0x24/0x80<br /> ? page_fault_oops+0x99/0x1b0<br /> ? do_user_addr_fault+0x2ee/0x6b0<br /> ? exc_page_fault+0x83/0x1b0<br /> ? asm_exc_page_fault+0x27/0x30<br /> ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]<br /> ? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]<br /> ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]<br /> ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]<br /> _sha256_update+0x77/0xa0 [sha256_ssse3]<br /> sha256_avx2_update+0x15/0x30 [sha256_ssse3]<br /> crypto_shash_update+0x1e/0x40<br /> hmac_update+0x12/0x20<br /> crypto_shash_update+0x1e/0x40<br /> generate_key+0x234/0x380 [ksmbd]<br /> generate_smb3encryptionkey+0x40/0x1c0 [ksmbd]<br /> ksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]<br /> ntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]<br /> smb2_sess_setup+0x952/0xaa0 [ksmbd]<br /> __process_request+0xa3/0x1d0 [ksmbd]<br /> __handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]<br /> handle_ksmbd_work+0x2d/0xa0 [ksmbd]<br /> process_one_work+0x16c/0x350<br /> worker_thread+0x306/0x440<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xef/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x44/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: dapm: Fix UAF for snd_soc_pcm_runtime object<br /> <br /> When using kernel with the following extra config,<br /> <br /> - CONFIG_KASAN=y<br /> - CONFIG_KASAN_GENERIC=y<br /> - CONFIG_KASAN_INLINE=y<br /> - CONFIG_KASAN_VMALLOC=y<br /> - CONFIG_FRAME_WARN=4096<br /> <br /> kernel detects that snd_pcm_suspend_all() access a freed<br /> &amp;#39;snd_soc_pcm_runtime&amp;#39; object when the system is suspended, which<br /> leads to a use-after-free bug:<br /> <br /> [ 52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270<br /> [ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330<br /> <br /> [ 52.047785] Call trace:<br /> [ 52.047787] dump_backtrace+0x0/0x3c0<br /> [ 52.047794] show_stack+0x34/0x50<br /> [ 52.047797] dump_stack_lvl+0x68/0x8c<br /> [ 52.047802] print_address_description.constprop.0+0x74/0x2c0<br /> [ 52.047809] kasan_report+0x210/0x230<br /> [ 52.047815] __asan_report_load1_noabort+0x3c/0x50<br /> [ 52.047820] snd_pcm_suspend_all+0x1a8/0x270<br /> [ 52.047824] snd_soc_suspend+0x19c/0x4e0<br /> <br /> The snd_pcm_sync_stop() has a NULL check on &amp;#39;substream-&gt;runtime&amp;#39; before<br /> making any access. So we need to always set &amp;#39;substream-&gt;runtime&amp;#39; to NULL<br /> everytime we kfree() it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sch/netem: fix use after free in netem_dequeue<br /> <br /> If netem_dequeue() enqueues packet to inner qdisc and that qdisc<br /> returns __NET_XMIT_STOLEN. The packet is dropped but<br /> qdisc_tree_reduce_backlog() is not called to update the parent&amp;#39;s<br /> q.qlen, leading to the similar use-after-free as Commit<br /> e04991a48dbaf382 ("netem: fix return value if duplicate enqueue<br /> fails")<br /> <br /> Commands to trigger KASAN UaF:<br /> <br /> ip link add type dummy<br /> ip link set lo up<br /> ip link set dummy0 up<br /> tc qdisc add dev lo parent root handle 1: drr<br /> tc filter add dev lo parent 1: basic classid 1:1<br /> tc class add dev lo classid 1:1 drr<br /> tc qdisc add dev lo parent 1:1 handle 2: netem<br /> tc qdisc add dev lo parent 2: handle 3: drr<br /> tc filter add dev lo parent 3: basic classid 3:1 action mirred egress<br /> redirect dev dummy0<br /> tc class add dev lo classid 3:1 drr<br /> ping -c1 -W0.01 localhost # Trigger bug<br /> tc class del dev lo classid 1:1<br /> tc class add dev lo classid 1:1 drr<br /> ping -c1 -W0.01 localhost # UaF

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Validate function returns<br /> <br /> [WHAT &amp; HOW]<br /> Function return values must be checked before data can be used<br /> in subsequent functions.<br /> <br /> This fixes 4 CHECKED_RETURN issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Run DC_LOG_DC after checking link-&gt;link_enc<br /> <br /> [WHAT]<br /> The DC_LOG_DC should be run after link-&gt;link_enc is checked, not before.<br /> <br /> This fixes 1 REVERSE_INULL issue reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check UnboundedRequestEnabled&amp;#39;s value<br /> <br /> CalculateSwathAndDETConfiguration_params_st&amp;#39;s UnboundedRequestEnabled<br /> is a pointer (i.e. dml_bool_t *UnboundedRequestEnabled), and thus<br /> if (p-&gt;UnboundedRequestEnabled) checks its address, not bool value.<br /> <br /> This fixes 1 REVERSE_INULL issue reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Free pvr_vm_gpuva after unlink<br /> <br /> This caused a measurable memory leak. Although the individual<br /> allocations are small, the leaks occurs in a high-usage codepath<br /> (remapping or unmapping device memory) so they add up quickly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eventfs: Use list_del_rcu() for SRCU protected list variable<br /> <br /> Chi Zhiling reported:<br /> <br /> We found a null pointer accessing in tracefs[1], the reason is that the<br /> variable &amp;#39;ei_child&amp;#39; is set to LIST_POISON1, that means the list was<br /> removed in eventfs_remove_rec. so when access the ei_child-&gt;is_freed, the<br /> panic triggered.<br /> <br /> by the way, the following script can reproduce this panic<br /> <br /> loop1 (){<br /> while true<br /> do<br /> echo "p:kp submit_bio" &gt; /sys/kernel/debug/tracing/kprobe_events<br /> echo "" &gt; /sys/kernel/debug/tracing/kprobe_events<br /> done<br /> }<br /> loop2 (){<br /> while true<br /> do<br /> tree /sys/kernel/debug/tracing/events/kprobes/<br /> done<br /> }<br /> loop1 &amp;<br /> loop2<br /> <br /> [1]:<br /> [ 1147.959632][T17331] Unable to handle kernel paging request at virtual address dead000000000150<br /> [ 1147.968239][T17331] Mem abort info:<br /> [ 1147.971739][T17331] ESR = 0x0000000096000004<br /> [ 1147.976172][T17331] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 1147.982171][T17331] SET = 0, FnV = 0<br /> [ 1147.985906][T17331] EA = 0, S1PTW = 0<br /> [ 1147.989734][T17331] FSC = 0x04: level 0 translation fault<br /> [ 1147.995292][T17331] Data abort info:<br /> [ 1147.998858][T17331] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 1148.005023][T17331] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 1148.010759][T17331] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 1148.016752][T17331] [dead000000000150] address between user and kernel address ranges<br /> [ 1148.024571][T17331] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 1148.030825][T17331] Modules linked in: team_mode_loadbalance team nlmon act_gact cls_flower sch_ingress bonding tls macvlan dummy ib_core bridge stp llc veth amdgpu amdxcp mfd_core gpu_sched drm_exec drm_buddy radeon crct10dif_ce video drm_suballoc_helper ghash_ce drm_ttm_helper sha2_ce ttm sha256_arm64 i2c_algo_bit sha1_ce sbsa_gwdt cp210x drm_display_helper cec sr_mod cdrom drm_kms_helper binfmt_misc sg loop fuse drm dm_mod nfnetlink ip_tables autofs4 [last unloaded: tls]<br /> [ 1148.072808][T17331] CPU: 3 PID: 17331 Comm: ls Tainted: G W ------- ---- 6.6.43 #2<br /> [ 1148.081751][T17331] Source Version: 21b3b386e948bedd29369af66f3e98ab01b1c650<br /> [ 1148.088783][T17331] Hardware name: Greatwall GW-001M1A-FTF/GW-001M1A-FTF, BIOS KunLun BIOS V4.0 07/16/2020<br /> [ 1148.098419][T17331] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1148.106060][T17331] pc : eventfs_iterate+0x2c0/0x398<br /> [ 1148.111017][T17331] lr : eventfs_iterate+0x2fc/0x398<br /> [ 1148.115969][T17331] sp : ffff80008d56bbd0<br /> [ 1148.119964][T17331] x29: ffff80008d56bbf0 x28: ffff001ff5be2600 x27: 0000000000000000<br /> [ 1148.127781][T17331] x26: ffff001ff52ca4e0 x25: 0000000000009977 x24: dead000000000100<br /> [ 1148.135598][T17331] x23: 0000000000000000 x22: 000000000000000b x21: ffff800082645f10<br /> [ 1148.143415][T17331] x20: ffff001fddf87c70 x19: ffff80008d56bc90 x18: 0000000000000000<br /> [ 1148.151231][T17331] x17: 0000000000000000 x16: 0000000000000000 x15: ffff001ff52ca4e0<br /> [ 1148.159048][T17331] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 1148.166864][T17331] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000804391d0<br /> [ 1148.174680][T17331] x8 : 0000000180000000 x7 : 0000000000000018 x6 : 0000aaab04b92862<br /> [ 1148.182498][T17331] x5 : 0000aaab04b92862 x4 : 0000000080000000 x3 : 0000000000000068<br /> [ 1148.190314][T17331] x2 : 000000000000000f x1 : 0000000000007ea8 x0 : 0000000000000001<br /> [ 1148.198131][T17331] Call trace:<br /> [ 1148.201259][T17331] eventfs_iterate+0x2c0/0x398<br /> [ 1148.205864][T17331] iterate_dir+0x98/0x188<br /> [ 1148.210036][T17331] __arm64_sys_getdents64+0x78/0x160<br /> [ 1148.215161][T17331] invoke_syscall+0x78/0x108<br /> [ 1148.219593][T17331] el0_svc_common.constprop.0+0x48/0xf0<br /> [ 1148.224977][T17331] do_el0_svc+0x24/0x38<br /> [ 1148.228974][T17331] el0_svc+0x40/0x168<br /> [ 1148.232798][T17<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> userfaultfd: fix checks for huge PMDs<br /> <br /> Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.<br /> <br /> The pmd_trans_huge() code in mfill_atomic() is wrong in three different<br /> ways depending on kernel version:<br /> <br /> 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit<br /> the right two race windows) - I&amp;#39;ve tested this in a kernel build with<br /> some extra mdelay() calls. See the commit message for a description<br /> of the race scenario.<br /> On older kernels (before 6.5), I think the same bug can even<br /> theoretically lead to accessing transhuge page contents as a page table<br /> if you hit the right 5 narrow race windows (I haven&amp;#39;t tested this case).<br /> 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for<br /> detecting PMDs that don&amp;#39;t point to page tables.<br /> On older kernels (before 6.5), you&amp;#39;d just have to win a single fairly<br /> wide race to hit this.<br /> I&amp;#39;ve tested this on 6.1 stable by racing migration (with a mdelay()<br /> patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86<br /> VM, that causes a kernel oops in ptlock_ptr().<br /> 3. On newer kernels (&gt;=6.5), for shmem mappings, khugepaged is allowed<br /> to yank page tables out from under us (though I haven&amp;#39;t tested that),<br /> so I think the BUG_ON() checks in mfill_atomic() are just wrong.<br /> <br /> I decided to write two separate fixes for these (one fix for bugs 1+2, one<br /> fix for bug 3), so that the first fix can be backported to kernels<br /> affected by bugs 1+2.<br /> <br /> <br /> This patch (of 2):<br /> <br /> This fixes two issues.<br /> <br /> I discovered that the following race can occur:<br /> <br /> mfill_atomic other thread<br /> ============ ============<br /> <br /> pmdp_get_lockless() [reads none pmd]<br /> <br /> <br /> <br /> __pte_alloc [no-op]<br /> <br /> <br /> BUG_ON(pmd_none(*dst_pmd))<br /> <br /> I have experimentally verified this in a kernel with extra mdelay() calls;<br /> the BUG_ON(pmd_none(*dst_pmd)) triggers.<br /> <br /> On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow<br /> pte_offset_map[_lock]() to fail"), this can&amp;#39;t lead to anything worse than<br /> a BUG_ON(), since the page table access helpers are actually designed to<br /> deal with page tables concurrently disappearing; but on older kernels<br /> (

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/osnoise: Use a cpumask to know what threads are kthreads<br /> <br /> The start_kthread() and stop_thread() code was not always called with the<br /> interface_lock held. This means that the kthread variable could be<br /> unexpectedly changed causing the kthread_stop() to be called on it when it<br /> should not have been, leading to:<br /> <br /> while true; do<br /> rtla timerlat top -u -q &amp; PID=$!;<br /> sleep 5;<br /> kill -INT $PID;<br /> sleep 0.001;<br /> kill -TERM $PID;<br /> wait $PID;<br /> done<br /> <br /> Causing the following OOPS:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:hrtimer_active+0x58/0x300<br /> Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f<br /> RSP: 0018:ffff88811d97f940 EFLAGS: 00010202<br /> RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b<br /> RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28<br /> RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60<br /> R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d<br /> R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28<br /> FS: 0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0<br /> Call Trace:<br /> <br /> ? die_addr+0x40/0xa0<br /> ? exc_general_protection+0x154/0x230<br /> ? asm_exc_general_protection+0x26/0x30<br /> ? hrtimer_active+0x58/0x300<br /> ? __pfx_mutex_lock+0x10/0x10<br /> ? __pfx_locks_remove_file+0x10/0x10<br /> hrtimer_cancel+0x15/0x40<br /> timerlat_fd_release+0x8e/0x1f0<br /> ? security_file_release+0x43/0x80<br /> __fput+0x372/0xb10<br /> task_work_run+0x11e/0x1f0<br /> ? _raw_spin_lock+0x85/0xe0<br /> ? __pfx_task_work_run+0x10/0x10<br /> ? poison_slab_object+0x109/0x170<br /> ? do_exit+0x7a0/0x24b0<br /> do_exit+0x7bd/0x24b0<br /> ? __pfx_migrate_enable+0x10/0x10<br /> ? __pfx_do_exit+0x10/0x10<br /> ? __pfx_read_tsc+0x10/0x10<br /> ? ktime_get+0x64/0x140<br /> ? _raw_spin_lock_irq+0x86/0xe0<br /> do_group_exit+0xb0/0x220<br /> get_signal+0x17ba/0x1b50<br /> ? vfs_read+0x179/0xa40<br /> ? timerlat_fd_read+0x30b/0x9d0<br /> ? __pfx_get_signal+0x10/0x10<br /> ? __pfx_timerlat_fd_read+0x10/0x10<br /> arch_do_signal_or_restart+0x8c/0x570<br /> ? __pfx_arch_do_signal_or_restart+0x10/0x10<br /> ? vfs_read+0x179/0xa40<br /> ? ksys_read+0xfe/0x1d0<br /> ? __pfx_ksys_read+0x10/0x10<br /> syscall_exit_to_user_mode+0xbc/0x130<br /> do_syscall_64+0x74/0x110<br /> ? __pfx___rseq_handle_notify_resume+0x10/0x10<br /> ? __pfx_ksys_read+0x10/0x10<br /> ? fpregs_restore_userregs+0xdb/0x1e0<br /> ? fpregs_restore_userregs+0xdb/0x1e0<br /> ? syscall_exit_to_user_mode+0x116/0x130<br /> ? do_syscall_64+0x74/0x110<br /> ? do_syscall_64+0x74/0x110<br /> ? do_syscall_64+0x74/0x110<br /> entry_SYSCALL_64_after_hwframe+0x71/0x79<br /> RIP: 0033:0x7ff0070eca9c<br /> Code: Unable to access opcode bytes at 0x7ff0070eca72.<br /> RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c<br /> RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003<br /> RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0<br /> R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003<br /> R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008<br /> <br /> Modules linked in: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This is because it would mistakenly call kthread_stop() on a user space<br /> thread making it "exit" before it actually exits.<br /> <br /> Since kthread<br /> ---truncated---