Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: verisilicon: AV1: Fix tile info buffer size<br /> <br /> Each tile info is composed of: row_sb, col_sb, start_pos<br /> and end_pos (4 bytes each). So the total required memory<br /> is AV1_MAX_TILES * 16 bytes.<br /> Use the correct #define to allocate the buffer and avoid<br /> writing tile info in non-allocated memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c/tw9903: Fix potential memory leak in tw9903_probe()<br /> <br /> In one of the error paths in tw9903_probe(), the memory allocated in<br /> v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that<br /> by calling v4l2_ctrl_handler_free() on the handler in that error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: iris: gen2: Add sanity check for session stop<br /> <br /> In iris_kill_session, inst-&gt;state is set to IRIS_INST_ERROR and<br /> session_close is executed, which will kfree(inst_hfi_gen2-&gt;packet).<br /> If stop_streaming is called afterward, it will cause a crash.<br /> <br /> Add a NULL check for inst_hfi_gen2-&gt;packet before sendling STOP packet<br /> to firmware to fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Drop the lock in skb_may_tx_timestamp()<br /> <br /> skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must<br /> not be taken in IRQ context, only softirq is okay. A few drivers receive<br /> the timestamp via a dedicated interrupt and complete the TX timestamp<br /> from that handler. This will lead to a deadlock if the lock is already<br /> write-locked on the same CPU.<br /> <br /> Taking the lock can be avoided. The socket (pointed by the skb) will<br /> remain valid until the skb is released. The -&gt;sk_socket and -&gt;file<br /> member will be set to NULL once the user closes the socket which may<br /> happen before the timestamp arrives.<br /> If we happen to observe the pointer while the socket is closing but<br /> before the pointer is set to NULL then we may use it because both<br /> pointer (and the file&amp;#39;s cred member) are RCU freed.<br /> <br /> Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a<br /> matching WRITE_ONCE() where the pointer are cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix locking usage for tcon fields<br /> <br /> We used to use the cifs_tcp_ses_lock to protect a lot of objects<br /> that are not just the server, ses or tcon lists. We later introduced<br /> srv_lock, ses_lock and tc_lock to protect fields within the<br /> corresponding structs. This was done to provide a more granular<br /> protection and avoid unnecessary serialization.<br /> <br /> There were still a couple of uses of cifs_tcp_ses_lock to provide<br /> tcon fields. In this patch, I&amp;#39;ve replaced them with tc_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi: ipmb: initialise event handler read bytes<br /> <br /> IPMB doesn&amp;#39;t use i2c reads, but the handler needs to set a value.<br /> Otherwise an i2c read will return an uninitialised value from the bus<br /> driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cpsw_new: Fix potential unregister of netdev that has not been registered yet<br /> <br /> If an error occurs during register_netdev() for the first MAC in<br /> cpsw_register_ports(), even though cpsw-&gt;slaves[0].ndev is set to NULL,<br /> cpsw-&gt;slaves[1].ndev would remain unchanged. This could later cause<br /> cpsw_unregister_ports() to attempt unregistering the second MAC.<br /> To address this, add a check for ndev-&gt;reg_state before calling<br /> unregister_netdev(). With this change, setting cpsw-&gt;slaves[i].ndev<br /> to NULL becomes unnecessary and can be removed accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: serialize sequence allocation under concurrent TLB invalidations<br /> <br /> With concurrent TLB invalidations, completion wait randomly gets timed out<br /> because cmd_sem_val was incremented outside the IOMMU spinlock, allowing<br /> CMD_COMPL_WAIT commands to be queued out of sequence and breaking the<br /> ordering assumption in wait_on_sem().<br /> Move the cmd_sem_val increment under iommu-&gt;lock so completion sequence<br /> allocation is serialized with command queuing.<br /> And remove the unnecessary return.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2()<br /> <br /> Add SRCU read-side protection when reading PDPTR registers in<br /> __get_sregs2().<br /> <br /> Reading PDPTRs may trigger access to guest memory:<br /> kvm_pdptr_read() -&gt; svm_cache_reg() -&gt; load_pdptrs() -&gt;<br /> kvm_vcpu_read_guest_page() -&gt; kvm_vcpu_gfn_to_memslot()<br /> <br /> kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(),<br /> which uses srcu_dereference_check() and requires either kvm-&gt;srcu or<br /> kvm-&gt;slots_lock to be held. Currently only vcpu-&gt;mutex is held,<br /> triggering lockdep warning:<br /> <br /> =============================<br /> WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot<br /> 6.12.59+ #3 Not tainted<br /> <br /> include/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by syz.5.1717/15100:<br /> #0: ff1100002f4b00b0 (&amp;vcpu-&gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120<br /> lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824<br /> __kvm_memslots include/linux/kvm_host.h:1062 [inline]<br /> __kvm_memslots include/linux/kvm_host.h:1059 [inline]<br /> kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline]<br /> kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617<br /> kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302<br /> load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065<br /> svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688<br /> kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline]<br /> __get_sregs2 arch/x86/kvm/x86.c:11784 [inline]<br /> kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279<br /> kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: pci: validate sequence number of TX release report<br /> <br /> Hardware rarely reports abnormal sequence number in TX release report,<br /> which will access out-of-bounds of wd_ring-&gt;pages array, causing NULL<br /> pointer dereference.<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 NOPTI<br /> CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U<br /> 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1)<br /> Call Trace:<br /> <br /> rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)]<br /> rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)]<br /> net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759<br /> handle_softirqs+0xbe/0x290 kernel/softirq.c:601<br /> ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)]<br /> __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423<br /> <br /> <br /> rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)]<br /> ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0<br /> irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314<br /> ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202<br /> ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220<br /> kthread+0xea/0x110 kernel/kthread.c:376<br /> ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287<br /> ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295<br /> <br /> <br /> To prevent crash, validate rpp_info.seq before using.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE<br /> <br /> The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE -<br /> which is a valid index - so add a check for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix pci_slot_trylock() error handling<br /> <br /> Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")<br /> delegates the bridge device&amp;#39;s pci_dev_trylock() to pci_bus_trylock() in<br /> pci_slot_trylock(), but it forgets to remove the corresponding<br /> pci_dev_unlock() when pci_bus_trylock() fails.<br /> <br /> Before a4e772898f8b, the code did:<br /> <br /> if (!pci_dev_trylock(dev)) /* subordinate) {<br /> if (!pci_bus_trylock(dev-&gt;subordinate)) {<br /> pci_dev_unlock(dev); /*