Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slab: fix kmalloc_nolock() context check for PREEMPT_RT<br /> <br /> On PREEMPT_RT kernels, local_lock becomes a sleeping lock. The current<br /> check in kmalloc_nolock() only verifies we&amp;#39;re not in NMI or hard IRQ<br /> context, but misses the case where preemption is disabled.<br /> <br /> When a BPF program runs from a tracepoint with preemption disabled<br /> (preempt_count &gt; 0), kmalloc_nolock() proceeds to call<br /> local_lock_irqsave() which attempts to acquire a sleeping lock,<br /> triggering:<br /> <br /> BUG: sleeping function called from invalid context<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128<br /> preempt_count: 2, expected: 0<br /> <br /> Fix this by checking !preemptible() on PREEMPT_RT, which directly<br /> expresses the constraint that we cannot take a sleeping lock when<br /> preemption is disabled. This encompasses the previous checks for NMI<br /> and hard IRQ contexts while also catching cases where preemption is<br /> disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: fix dma_free_coherent() pointer<br /> <br /> dma_alloc_coherent() allocates a DMA mapped buffer and stores the<br /> addresses in XXX_unaligned fields. Those should be reused when freeing<br /> the buffer rather than the aligned addresses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: synopsys: dw-dp: fix error paths of dw_dp_bind<br /> <br /> Fix several issues in dw_dp_bind() error handling:<br /> <br /> 1. Missing return after drm_bridge_attach() failure - the function<br /> continued execution instead of returning an error.<br /> <br /> 2. Resource leak: drm_dp_aux_register() is not a devm function, so<br /> drm_dp_aux_unregister() must be called on all error paths after<br /> aux registration succeeds. This affects errors from:<br /> - drm_bridge_attach()<br /> - phy_init()<br /> - devm_add_action_or_reset()<br /> - platform_get_irq()<br /> - devm_request_threaded_irq()<br /> <br /> 3. Bug fix: platform_get_irq() returns the IRQ number or a negative<br /> error code, but the error path was returning ERR_PTR(ret) instead<br /> of ERR_PTR(dp-&gt;irq).<br /> <br /> Use a goto label for cleanup to ensure consistent error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/sva: invalidate stale IOTLB entries for kernel address space<br /> <br /> Introduce a new IOMMU interface to flush IOTLB paging cache entries for<br /> the CPU kernel address space. This interface is invoked from the x86<br /> architecture code that manages combined user and kernel page tables,<br /> specifically before any kernel page table page is freed and reused.<br /> <br /> This addresses the main issue with vfree() which is a common occurrence<br /> and can be triggered by unprivileged users. While this resolves the<br /> primary problem, it doesn&amp;#39;t address some extremely rare case related to<br /> memory unplug of memory that was present as reserved memory at boot, which<br /> cannot be triggered by unprivileged users. The discussion can be found at<br /> the link below.<br /> <br /> Enable SVA on x86 architecture since the IOMMU can now receive<br /> notification to flush the paging cache before freeing the CPU kernel page<br /> table pages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix early read unlock of page with EOF in middle<br /> <br /> The read result collection for buffered reads seems to run ahead of the<br /> completion of subrequests under some circumstances, as can be seen in the<br /> following log snippet:<br /> <br /> 9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0<br /> ...<br /> netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0<br /> ...<br /> netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2<br /> netfs_folio: i=157f3 ix=00004-00004 read-done<br /> netfs_folio: i=157f3 ix=00004-00004 read-unlock<br /> netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2<br /> netfs_folio: i=157f3 ix=00005-00005 read-done<br /> netfs_folio: i=157f3 ix=00005-00005 read-unlock<br /> ...<br /> netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff<br /> netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c<br /> netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff<br /> netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8<br /> ...<br /> netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0<br /> netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0<br /> <br /> The &amp;#39;cto=5fb2&amp;#39; indicates the collected file pos we&amp;#39;ve collected results to<br /> so far - but we still have 0x4e more bytes to go - so we shouldn&amp;#39;t have<br /> collected folio ix=00005 yet. The &amp;#39;ZERO&amp;#39; subreq that clears the tail<br /> happens after we unlock the folio, allowing the application to see the<br /> uncleared tail through mmap.<br /> <br /> The problem is that netfs_read_unlock_folios() will unlock a folio in which<br /> the amount of read results collected hits EOF position - but the ZERO<br /> subreq lies beyond that and so happens after.<br /> <br /> Fix this by changing the end check to always be the end of the folio and<br /> never the end of the file.<br /> <br /> In the future, I should look at clearing to the end of the folio here rather<br /> than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can<br /> run in parallel with an async READ subreq. Further, the ZERO subreq may still<br /> be necessary to, say, handle extents in a ceph file that don&amp;#39;t have any<br /> backing store and are thus implicitly all zeros.<br /> <br /> This can be reproduced by creating a file, the size of which doesn&amp;#39;t align<br /> to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something<br /> like:<br /> <br /> xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \<br /> -c "mread -v 0 0x6000" /xfstest.test/x<br /> <br /> The last 0x4e bytes should all be 00, but if the tail hasn&amp;#39;t been cleared<br /> yet, you may see rubbish there. This can be reproduced with kafs by<br /> modifying the kernel to disable the call to netfs_read_subreq_progress()<br /> and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD.<br /> Reproduction can be made easier by inserting an mdelay(100) in<br /> netfs_issue_read() for the ZERO-subreq case.<br /> <br /> AFS and CIFS are normally unlikely to show this as they dispatch READ ops<br /> asynchronously, which allows the ZERO-subreq to finish first. 9P&amp;#39;s READ op is<br /> completely synchronous, so the ZERO-subreq will always happen after. It isn&amp;#39;t<br /> seen all the time, though, because the collection may be done in a worker<br /> thread.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names<br /> <br /> The hp-bioscfg driver attempts to register kobjects with empty names when<br /> the HP BIOS returns attributes with empty name strings. This causes<br /> multiple kernel warnings:<br /> <br /> kobject: (00000000135fb5e6): attempted to be registered with empty name!<br /> WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310<br /> <br /> Add validation in hp_init_bios_buffer_attribute() to check if the<br /> attribute name is empty after parsing it from the WMI buffer. If empty,<br /> log a debug message and skip registration of that attribute, allowing the<br /> module to continue processing other valid attributes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix dead lock while flushing management frames<br /> <br /> Commit [1] converted the management transmission work item into a<br /> wiphy work. Since a wiphy work can only run under wiphy lock<br /> protection, a race condition happens in below scenario:<br /> <br /> 1. a management frame is queued for transmission.<br /> 2. ath12k_mac_op_flush() gets called to flush pending frames associated<br /> with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush()<br /> the process waits for the transmission done.<br /> 3. Since wiphy lock has been taken by the flush process, the transmission<br /> work item has no chance to run, hence the dead lock.<br /> <br /> &gt;From user view, this dead lock results in below issue:<br /> <br /> wlp8s0: authenticate with xxxxxx (local address=xxxxxx)<br /> wlp8s0: send auth to xxxxxx (try 1/3)<br /> wlp8s0: authenticate with xxxxxx (local address=xxxxxx)<br /> wlp8s0: send auth to xxxxxx (try 1/3)<br /> wlp8s0: authenticated<br /> wlp8s0: associate with xxxxxx (try 1/3)<br /> wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING)<br /> ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1<br /> <br /> The dead lock can be avoided by invoking wiphy_work_flush() to proactively<br /> run the queued work item. Note actually it is already present in<br /> ath12k_mac_op_flush(), however it does not protect the case where vif<br /> being NULL. Hence move it ahead to cover this case as well.<br /> <br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: Prevent duplicate registrations<br /> <br /> Modify the internal registration helpers dpll_xa_ref_{dpll,pin}_add()<br /> to reject duplicate registration attempts.<br /> <br /> Previously, if a caller attempted to register the same pin multiple<br /> times (with the same ops, priv, and cookie) on the same device, the core<br /> silently increments the reference count and return success. This behavior<br /> is incorrect because if the caller makes these duplicate registrations<br /> then for the first one dpll_pin_registration is allocated and for others<br /> the associated dpll_pin_ref.refcount is incremented. During the first<br /> unregistration the associated dpll_pin_registration is freed and for<br /> others WARN is fired.<br /> <br /> Fix this by updating the logic to return `-EEXIST` if a matching<br /> registration is found to enforce a strict "register once" policy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: Set __nocfi on swsusp_arch_resume()<br /> <br /> A DABT is reported[1] on an android based system when resume from hiberate.<br /> This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*()<br /> and does not have a CFI hash, but swsusp_arch_resume() will attempt to<br /> verify the CFI hash when calling a copy of swsusp_arch_suspend_exit().<br /> <br /> Given that there&amp;#39;s an existing requirement that the entrypoint to<br /> swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text<br /> section, we cannot fix this by marking swsusp_arch_suspend_exit() with<br /> SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in<br /> swsusp_arch_resume().<br /> <br /> Mark swsusp_arch_resume() as __nocfi to disable the CFI check.<br /> <br /> [1]<br /> [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc<br /> [ 22.991934][ T1] Mem abort info:<br /> [ 22.991934][ T1] ESR = 0x0000000096000007<br /> [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 22.991934][ T1] SET = 0, FnV = 0<br /> [ 22.991934][ T1] EA = 0, S1PTW = 0<br /> [ 22.991934][ T1] FSC = 0x07: level 3 translation fault<br /> [ 22.991934][ T1] Data abort info:<br /> [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000<br /> [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper<br /> [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP<br /> [ 22.991934][ T1] Dumping ftrace buffer:<br /> [ 22.991934][ T1] (ftrace buffer empty)<br /> [ 22.991934][ T1] Modules linked in:<br /> [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419<br /> [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT)<br /> [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344<br /> [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344<br /> [ 22.991934][ T1] sp : ffffffc08006b960<br /> [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820<br /> [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000<br /> [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058<br /> [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004<br /> [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000<br /> [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000<br /> [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b<br /> [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530<br /> [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000<br /> [ 22.991934][ T1] Call trace:<br /> [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344<br /> [ 22.991934][ T1] hibernation_restore+0x158/0x18c<br /> [ 22.991934][ T1] load_image_and_restore+0xb0/0xec<br /> [ 22.991934][ T1] software_resume+0xf4/0x19c<br /> [ 22.991934][ T1] software_resume_initcall+0x34/0x78<br /> [ 22.991934][ T1] do_one_initcall+0xe8/0x370<br /> [ 22.991934][ T1] do_initcall_level+0xc8/0x19c<br /> [ 22.991934][ T1] do_initcalls+0x70/0xc0<br /> [ 22.991934][ T1] do_basic_setup+0x1c/0x28<br /> [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148<br /> [ 22.991934][ T1] kernel_init+0x20/0x1a8<br /> [ 22.991934][ T1] ret_from_fork+0x10/0x20<br /> [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)<br /> <br /> [catalin.marinas@arm.com: commit log updated by Mark Rutland]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: annotate data-race around dev-&gt;work<br /> <br /> dev-&gt;work can re read locklessly in mISDN_read()<br /> and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations.<br /> <br /> BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read<br /> <br /> write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1:<br /> misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline]<br /> mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583<br /> __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583<br /> x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0:<br /> mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112<br /> do_loop_readv_writev fs/read_write.c:847 [inline]<br /> vfs_readv+0x3fb/0x690 fs/read_write.c:1020<br /> do_readv+0xe7/0x210 fs/read_write.c:1080<br /> __do_sys_readv fs/read_write.c:1165 [inline]<br /> __se_sys_readv fs/read_write.c:1162 [inline]<br /> __x64_sys_readv+0x45/0x50 fs/read_write.c:1162<br /> x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> value changed: 0x00000000 -&gt; 0x00000001

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: avoid one data-race in l2tp_tunnel_del_work()<br /> <br /> We should read sk-&gt;sk_socket only when dealing with kernel sockets.<br /> <br /> syzbot reported the following data-race:<br /> <br /> BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release<br /> <br /> write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:<br /> sk_set_socket include/net/sock.h:2092 [inline]<br /> sock_orphan include/net/sock.h:2118 [inline]<br /> sk_common_release+0xae/0x230 net/core/sock.c:4003<br /> udp_lib_close+0x15/0x20 include/net/udp.h:325<br /> inet_release+0xce/0xf0 net/ipv4/af_inet.c:437<br /> __sock_release net/socket.c:662 [inline]<br /> sock_close+0x6b/0x150 net/socket.c:1455<br /> __fput+0x29b/0x650 fs/file_table.c:468<br /> ____fput+0x1c/0x30 fs/file_table.c:496<br /> task_work_run+0x131/0x1a0 kernel/task_work.c:233<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]<br /> exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75<br /> __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]<br /> syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]<br /> do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:<br /> l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340<br /> worker_thread+0x582/0x770 kernel/workqueue.c:3421<br /> kthread+0x489/0x510 kernel/kthread.c:463<br /> ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> value changed: 0xffff88811b818000 -&gt; 0x0000000000000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: provide a net pointer to __skb_flow_dissect()<br /> <br /> After 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect")<br /> we have to provide a net pointer to __skb_flow_dissect(),<br /> either via skb-&gt;dev, skb-&gt;sk, or a user provided pointer.<br /> <br /> In the following case, syzbot was able to cook a bare skb.<br /> <br /> WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053<br /> Call Trace:<br /> <br /> bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline]<br /> __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157<br /> bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline]<br /> bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline]<br /> bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515<br /> xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388<br /> bpf_prog_run_xdp include/net/xdp.h:700 [inline]<br /> bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421<br /> bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390<br /> bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703<br /> __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182<br /> __do_sys_bpf kernel/bpf/syscall.c:6274 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:6272 [inline]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94