Vulnerabilities

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 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not BUG_ON() when freeing tree block after error<br /> <br /> When freeing a tree block, at btrfs_free_tree_block(), if we fail to<br /> create a delayed reference we don&amp;#39;t deal with the error and just do a<br /> BUG_ON(). The error most likely to happen is -ENOMEM, and we have a<br /> comment mentioning that only -ENOMEM can happen, but that is not true,<br /> because in case qgroups are enabled any error returned from<br /> btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned<br /> from btrfs_search_slot() for example) can be propagated back to<br /> btrfs_free_tree_block().<br /> <br /> So stop doing a BUG_ON() and return the error to the callers and make<br /> them abort the transaction to prevent leaking space. Syzbot was<br /> triggering this, likely due to memory allocation failure injection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leaks and crashes while performing a soft reset<br /> <br /> The second tagged commit introduced a UAF, as it removed restoring<br /> q_vector-&gt;vport pointers after reinitializating the structures.<br /> This is due to that all queue allocation functions are performed here<br /> with the new temporary vport structure and those functions rewrite<br /> the backpointers to the vport. Then, this new struct is freed and<br /> the pointers start leading to nowhere.<br /> <br /> But generally speaking, the current logic is very fragile. It claims<br /> to be more reliable when the system is low on memory, but in fact, it<br /> consumes two times more memory as at the moment of running this<br /> function, there are two vports allocated with their queues and vectors.<br /> Moreover, it claims to prevent the driver from running into "bad state",<br /> but in fact, any error during the rebuild leaves the old vport in the<br /> partially allocated state.<br /> Finally, if the interface is down when the function is called, it always<br /> allocates a new queue set, but when the user decides to enable the<br /> interface later on, vport_open() allocates them once again, IOW there&amp;#39;s<br /> a clear memory leak here.<br /> <br /> Just don&amp;#39;t allocate a new queue set when performing a reset, that solves<br /> crashes and memory leaks. Readd the old queue number and reopen the<br /> interface on rollback - that solves limbo states when the device is left<br /> disabled and/or without HW queues enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: sc16is7xx: fix invalid FIFO access with special register set<br /> <br /> When enabling access to the special register set, Receiver time-out and<br /> RHR interrupts can happen. In this case, the IRQ handler will try to read<br /> from the FIFO thru the RHR register at address 0x00, but address 0x00 is<br /> mapped to DLL register, resulting in erroneous FIFO reading.<br /> <br /> Call graph example:<br /> sc16is7xx_startup(): entry<br /> sc16is7xx_ms_proc(): entry<br /> sc16is7xx_set_termios(): entry<br /> sc16is7xx_set_baud(): DLH/DLL = $009C --&gt; access special register set<br /> sc16is7xx_port_irq() entry --&gt; IIR is 0x0C<br /> sc16is7xx_handle_rx() entry<br /> sc16is7xx_fifo_read(): --&gt; unable to access FIFO (RHR) because it is<br /> mapped to DLL (LCR=LCR_CONF_MODE_A)<br /> sc16is7xx_set_baud(): exit --&gt; Restore access to general register set<br /> <br /> Fix the problem by claiming the efr_lock mutex when accessing the Special<br /> register set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: fix a possible DMA corruption<br /> <br /> ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be<br /> possible that two unrelated 16-byte allocations share a cache line. If<br /> one of these allocations is written using DMA and the other is written<br /> using cached write, the value that was written with DMA may be<br /> corrupted.<br /> <br /> This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -<br /> that&amp;#39;s the largest possible cache line size.<br /> <br /> As different parisc microarchitectures have different cache line size, we<br /> define arch_slab_minalign(), cache_line_size() and<br /> dma_get_cache_alignment() so that the kernel may tune slab cache<br /> parameters dynamically, based on the detected cache line size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: line6: Fix racy access to midibuf<br /> <br /> There can be concurrent accesses to line6 midibuf from both the URB<br /> completion callback and the rawmidi API access. This could be a cause<br /> of KMSAN warning triggered by syzkaller below (so put as reported-by<br /> here).<br /> <br /> This patch protects the midibuf call of the former code path with a<br /> spinlock for avoiding the possible races.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/smt: Fix unbalance sched_smt_present dec/inc<br /> <br /> I got the following warn report while doing stress test:<br /> <br /> jump label: negative count!<br /> WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0<br /> Call Trace:<br /> <br /> __static_key_slow_dec_cpuslocked+0x16/0x70<br /> sched_cpu_deactivate+0x26e/0x2a0<br /> cpuhp_invoke_callback+0x3ad/0x10d0<br /> cpuhp_thread_fun+0x3f5/0x680<br /> smpboot_thread_fn+0x56d/0x8d0<br /> kthread+0x309/0x400<br /> ret_from_fork+0x41/0x70<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),<br /> the cpu offline failed, but sched_smt_present is decremented before<br /> calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so<br /> fix it by incrementing sched_smt_present in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: core: Check for unset descriptor<br /> <br /> Make sure the descriptor has been set before looking at maxpacket.<br /> This fixes a null pointer panic in this case.<br /> <br /> This may happen if the gadget doesn&amp;#39;t properly set up the endpoint<br /> for the current speed, or the gadget descriptors are malformed and<br /> the descriptor for the speed/endpoint are not found.<br /> <br /> No current gadget driver is known to have this problem, but this<br /> may cause a hard-to-find bug during development of new gadgets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Fix pti_clone_pgtable() alignment assumption<br /> <br /> Guenter reported dodgy crashes on an i386-nosmp build using GCC-11<br /> that had the form of endless traps until entry stack exhaust and then<br /> #DF from the stack guard.<br /> <br /> It turned out that pti_clone_pgtable() had alignment assumptions on<br /> the start address, notably it hard assumes start is PMD aligned. This<br /> is true on x86_64, but very much not true on i386.<br /> <br /> These assumptions can cause the end condition to malfunction, leading<br /> to a &amp;#39;short&amp;#39; clone. Guess what happens when the user mapping has a<br /> short copy of the entry text?<br /> <br /> Use the correct increment form for addr to avoid alignment<br /> assumptions.