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 /> fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF<br /> <br /> The fscache_cookie_lru_timer is initialized when the fscache module<br /> is inserted, but is not deleted when the fscache module is removed.<br /> If timer_reduce() is called before removing the fscache module,<br /> the fscache_cookie_lru_timer will be added to the timer list of<br /> the current cpu. Afterwards, a use-after-free will be triggered<br /> in the softIRQ after removing the fscache module, as follows:<br /> <br /> ==================================================================<br /> BUG: unable to handle page fault for address: fffffbfff803c9e9<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855<br /> Tainted: [W]=WARN<br /> RIP: 0010:__run_timer_base.part.0+0x254/0x8a0<br /> Call Trace:<br /> <br /> tmigr_handle_remote_up+0x627/0x810<br /> __walk_groups.isra.0+0x47/0x140<br /> tmigr_handle_remote+0x1fa/0x2f0<br /> handle_softirqs+0x180/0x590<br /> irq_exit_rcu+0x84/0xb0<br /> sysvec_apic_timer_interrupt+0x6e/0x90<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x1a/0x20<br /> RIP: 0010:default_idle+0xf/0x20<br /> default_idle_call+0x38/0x60<br /> do_idle+0x2b5/0x300<br /> cpu_startup_entry+0x54/0x60<br /> start_secondary+0x20d/0x280<br /> common_startup_64+0x13e/0x148<br /> <br /> Modules linked in: [last unloaded: netfs]<br /> ==================================================================<br /> <br /> Therefore delete fscache_cookie_lru_timer when removing the fscahe module.

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 /> (