Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink<br /> <br /> When all the strides in a WQE have been consumed, the WQE is unlinked<br /> from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible<br /> to receive CQEs with 0 consumed strides for the same WQE even after the<br /> WQE is fully consumed and unlinked. This triggers an additional unlink<br /> for the same wqe which corrupts the linked list.<br /> <br /> Fix this scenario by accepting 0 sized consumed strides without<br /> unlinking the WQE again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()<br /> <br /> bcm_sf2_mdio_register() calls of_phy_find_device() and then<br /> phy_device_remove() in a loop to remove existing PHY devices.<br /> of_phy_find_device() eventually calls bus_find_device(), which calls<br /> get_device() on the returned struct device * to increment the refcount.<br /> The current implementation does not decrement the refcount, which causes<br /> memory leak.<br /> <br /> This commit adds the missing phy_device_free() call to decrement the<br /> refcount via put_device() to balance the refcount.

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 /> serial: sc16is7xx: fix TX fifo corruption<br /> <br /> Sometimes, when a packet is received on channel A at almost the same time<br /> as a packet is about to be transmitted on channel B, we observe with a<br /> logic analyzer that the received packet on channel A is transmitted on<br /> channel B. In other words, the Tx buffer data on channel B is corrupted<br /> with data from channel A.<br /> <br /> The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change<br /> EFR lock to operate on each channels"), which changed the EFR locking to<br /> operate on each channel instead of chip-wise.<br /> <br /> This commit has introduced a regression, because the EFR lock is used not<br /> only to protect the EFR registers access, but also, in a very obscure and<br /> undocumented way, to protect access to the data buffer, which is shared by<br /> the Tx and Rx handlers, but also by each channel of the IC.<br /> <br /> Fix this regression first by switching to kfifo_out_linear_ptr() in<br /> sc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.<br /> <br /> Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for<br /> each channel.

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 /> scsi: ufs: core: Fix deadlock during RTC update<br /> <br /> There is a deadlock when runtime suspend waits for the flush of RTC work,<br /> and the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume.<br /> <br /> Here is deadlock backtrace:<br /> <br /> kworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367<br /> ptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff<br /> __switch_to+0x1a8/0x2d4<br /> __schedule+0x684/0xa98<br /> schedule+0x48/0xc8<br /> schedule_timeout+0x48/0x170<br /> do_wait_for_common+0x108/0x1b0<br /> wait_for_completion+0x44/0x60<br /> __flush_work+0x39c/0x424<br /> __cancel_work_sync+0xd8/0x208<br /> cancel_delayed_work_sync+0x14/0x28<br /> __ufshcd_wl_suspend+0x19c/0x480<br /> ufshcd_wl_runtime_suspend+0x3c/0x1d4<br /> scsi_runtime_suspend+0x78/0xc8<br /> __rpm_callback+0x94/0x3e0<br /> rpm_suspend+0x2d4/0x65c<br /> __pm_runtime_suspend+0x80/0x114<br /> scsi_runtime_idle+0x38/0x6c<br /> rpm_idle+0x264/0x338<br /> __pm_runtime_idle+0x80/0x110<br /> ufshcd_rtc_work+0x128/0x1e4<br /> process_one_work+0x26c/0x650<br /> worker_thread+0x260/0x3d8<br /> kthread+0x110/0x134<br /> ret_from_fork+0x10/0x20<br /> <br /> Skip updating RTC if RPM state is not RPM_ACTIVE.

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 /> drm/xe/preempt_fence: enlarge the fence critical section<br /> <br /> It is really easy to introduce subtle deadlocks in<br /> preempt_fence_work_func() since we operate on single global ordered-wq<br /> for signalling our preempt fences behind the scenes, so even though we<br /> signal a particular fence, everything in the callback should be in the<br /> fence critical section, since blocking in the callback will prevent<br /> other published fences from signalling. If we enlarge the fence critical<br /> section to cover the entire callback, then lockdep should be able to<br /> understand this better, and complain if we grab a sensitive lock like<br /> vm-&gt;lock, which is also held when waiting on preempt fences.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen: privcmd: Switch from mutex to spinlock for irqfds<br /> <br /> irqfd_wakeup() gets EPOLLHUP, when it is called by<br /> eventfd_release() by way of wake_up_poll(&amp;ctx-&gt;wqh, EPOLLHUP), which<br /> gets called under spin_lock_irqsave(). We can&amp;#39;t use a mutex here as it<br /> will lead to a deadlock.<br /> <br /> Fix it by switching over to a spin lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracefs: Use generic inode RCU for synchronizing freeing<br /> <br /> With structure layout randomization enabled for &amp;#39;struct inode&amp;#39; we need to<br /> avoid overlapping any of the RCU-used / initialized-only-once members,<br /> e.g. i_lru or i_sb_list to not corrupt related list traversals when making<br /> use of the rcu_head.<br /> <br /> For an unlucky structure layout of &amp;#39;struct inode&amp;#39; we may end up with the<br /> following splat when running the ftrace selftests:<br /> <br /> [] list_del corruption, ffff888103ee2cb0-&gt;next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object])<br /> [] ------------[ cut here ]------------<br /> [] kernel BUG at lib/list_debug.c:54!<br /> [] invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> [] CPU: 3 PID: 2550 Comm: mount Tainted: G N 6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65<br /> [] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014<br /> [] RIP: 0010:[] __list_del_entry_valid_or_report+0x138/0x3e0<br /> [] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f<br /> [] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283<br /> [] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000<br /> [] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001<br /> [] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25<br /> [] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d<br /> [] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000<br /> [] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object]<br /> [] RDX: __list_del_entry_valid_or_report+0x108/0x3e0<br /> [] RSI: __func__.47+0x4340/0x4400<br /> [] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object]<br /> [] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550]<br /> [] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550]<br /> [] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550]<br /> [] R14: tracefs_inode_cache+0x78/0x4e0 [slab object]<br /> [] FS: 00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000<br /> [] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0<br /> [] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [] ASID: 0003<br /> [] Stack:<br /> [] ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0<br /> [] ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f<br /> [] 0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392<br /> [] Call Trace:<br /> [] <br /> [] [] ? lock_release+0x175/0x380 fffffe80416afaf0<br /> [] [] list_lru_del+0x152/0x740 fffffe80416afb48<br /> [] [] list_lru_del_obj+0x113/0x280 fffffe80416afb88<br /> [] [] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90<br /> [] [] iput_final+0x1c4/0x9a0 fffffe80416afbb8<br /> [] [] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8<br /> [] [] __dentry_kill+0x23c/0xf00 fffffe80416afc40<br /> [] [] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48<br /> [] [] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70<br /> [] [] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78<br /> [] [] shrink_dentry_list+0x288/0x760 fffffe80416afc80<br /> [] [] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8<br /> [] [] ? debug_smp_processor_id+0x23/0xa0 fffffe80416afce0<br /> [] [] ? do_one_tre<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Forward soft recovery errors to userspace<br /> <br /> As we discussed before[1], soft recovery should be<br /> forwarded to userspace, or we can get into a really<br /> bad state where apps will keep submitting hanging<br /> command buffers cascading us to a hard reset.<br /> <br /> 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/<br /> (cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading<br /> <br /> When unload the btnxpuart driver, its associated timer will be deleted.<br /> If the timer happens to be modified at this moment, it leads to the<br /> kernel call this timer even after the driver unloaded, resulting in<br /> kernel panic.<br /> Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming.<br /> <br /> panic log:<br /> Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP<br /> Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart]<br /> CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1<br /> Hardware name: NXP i.MX95 19X19 board (DT)<br /> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : 0xffff80007a2cf464<br /> lr : call_timer_fn.isra.0+0x24/0x80<br /> ...<br /> Call trace:<br /> 0xffff80007a2cf464<br /> __run_timers+0x234/0x280<br /> run_timer_softirq+0x20/0x40<br /> __do_softirq+0x100/0x26c<br /> ____do_softirq+0x10/0x1c<br /> call_on_irq_stack+0x24/0x4c<br /> do_softirq_own_stack+0x1c/0x2c<br /> irq_exit_rcu+0xc0/0xdc<br /> el0_interrupt+0x54/0xd8<br /> __el0_irq_handler_common+0x18/0x24<br /> el0t_64_irq_handler+0x10/0x1c<br /> el0t_64_irq+0x190/0x194<br /> Code: ???????? ???????? ???????? ???????? (????????)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> SMP: stopping secondary CPUs<br /> Kernel Offset: disabled<br /> CPU features: 0x0,c0000000,40028143,1000721b<br /> Memory Limit: none<br /> ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---