Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mtrr: Check if fixed MTRRs exist before saving them<br /> <br /> MTRRs have an obsolete fixed variant for fine grained caching control<br /> of the 640K-1MB region that uses separate MSRs. This fixed variant has<br /> a separate capability bit in the MTRR capability MSR.<br /> <br /> So far all x86 CPUs which support MTRR have this separate bit set, so it<br /> went unnoticed that mtrr_save_state() does not check the capability bit<br /> before accessing the fixed MTRR MSRs.<br /> <br /> Though on a CPU that does not support the fixed MTRR capability this<br /> results in a #GP. The #GP itself is harmless because the RDMSR fault is<br /> handled gracefully, but results in a WARN_ON().<br /> <br /> Add the missing capability check to prevent this.

A vulnerability was found in ?????????? Yunke Online School System up to 1.5.5. It has been declared as problematic. This vulnerability affects unknown code of the file /admin/educloud/videobind.html. The manipulation leads to inclusion of sensitive information in source code. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.5.6 is able to address this issue. It is recommended to upgrade the affected component.