Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked<br /> <br /> When `ksmbd_vfs_kern_path_locked` met an error and it is not the last<br /> entry, it will exit without restoring changed path buffer. But later this<br /> buffer may be used as the filename for creation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix variable not being completed when function returns<br /> <br /> When cmd_alloc_index(), fails cmd_work_handler() needs<br /> to complete ent-&gt;slotted before returning early.<br /> Otherwise the task which issued the command may hang:<br /> <br /> mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry<br /> INFO: task kworker/13:2:4055883 blocked for more than 120 seconds.<br /> Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> kworker/13:2 D 0 4055883 2 0x00000228<br /> Workqueue: events mlx5e_tx_dim_work [mlx5_core]<br /> Call trace:<br /> __switch_to+0xe8/0x150<br /> __schedule+0x2a8/0x9b8<br /> schedule+0x2c/0x88<br /> schedule_timeout+0x204/0x478<br /> wait_for_common+0x154/0x250<br /> wait_for_completion+0x28/0x38<br /> cmd_exec+0x7a0/0xa00 [mlx5_core]<br /> mlx5_cmd_exec+0x54/0x80 [mlx5_core]<br /> mlx5_core_modify_cq+0x6c/0x80 [mlx5_core]<br /> mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core]<br /> mlx5e_tx_dim_work+0x54/0x68 [mlx5_core]<br /> process_one_work+0x1b0/0x448<br /> worker_thread+0x54/0x468<br /> kthread+0x134/0x138<br /> ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: mm: Fix the out of bound issue of vmemmap address<br /> <br /> In sparse vmemmap model, the virtual address of vmemmap is calculated as:<br /> ((struct page *)VMEMMAP_START - (phys_ram_base &gt;&gt; PAGE_SHIFT)).<br /> And the struct page&amp;#39;s va can be calculated with an offset:<br /> (vmemmap + (pfn)).<br /> <br /> However, when initializing struct pages, kernel actually starts from the<br /> first page from the same section that phys_ram_base belongs to. If the<br /> first page&amp;#39;s physical address is not (phys_ram_base &gt;&gt; PAGE_SHIFT), then<br /> we get an va below VMEMMAP_START when calculating va for it&amp;#39;s struct page.<br /> <br /> For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the<br /> first page in the same section is actually pfn 0x80000. During<br /> init_unavailable_range(), we will initialize struct page for pfn 0x80000<br /> with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is<br /> below VMEMMAP_START as well as PCI_IO_END.<br /> <br /> This commit fixes this bug by introducing a new variable<br /> &amp;#39;vmemmap_start_pfn&amp;#39; which is aligned with memory section size and using<br /> it to calculate vmemmap address instead of phys_ram_base.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled<br /> <br /> When the caching for a cookie is temporarily disabled (e.g. due to a DIO<br /> write on that file), future copying to the cache for that file is disabled<br /> until all fds open on that file are closed. However, if netfslib is using<br /> the deprecated PG_private_2 method (such as is currently used by ceph), and<br /> decides it wants to copy to the cache, netfs_advance_write() will just bail<br /> at the first check seeing that the cache stream is unavailable, and<br /> indicate that it dealt with all the content.<br /> <br /> This means that we have no subrequests to provide notifications to drive<br /> the state machine or even to pin the request and the request just gets<br /> discarded, leaving the folios with PG_private_2 set.<br /> <br /> Fix this by jumping directly to cancel the request if the cache is not<br /> available. That way, we don&amp;#39;t remove mark3 from the folio_queue list and<br /> netfs_pgpriv2_cancel() will clean up the folios.<br /> <br /> This was found by running the generic/013 xfstest against ceph with an<br /> active cache and the "-o fsc" option passed to ceph. That would usually<br /> hang

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix ceph copy to cache on write-begin<br /> <br /> At the end of netfs_unlock_read_folio() in which folios are marked<br /> appropriately for copying to the cache (either with by being marked dirty<br /> and having their private data set or by having PG_private_2 set) and then<br /> unlocked, the folio_queue struct has the entry pointing to the folio<br /> cleared. This presents a problem for netfs_pgpriv2_write_to_the_cache(),<br /> which is used to write folios marked with PG_private_2 to the cache as it<br /> expects to be able to trawl the folio_queue list thereafter to find the<br /> relevant folios, leading to a hang.<br /> <br /> Fix this by not clearing the folio_queue entry if we&amp;#39;re going to do the<br /> deprecated copy-to-cache. The clearance will be done instead as the folios<br /> are written to the cache.<br /> <br /> This can be reproduced by starting cachefiles, mounting a ceph filesystem<br /> with "-o fsc" and writing to it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix the new buffer was not zeroed before writing<br /> <br /> Before writing, if a buffer_head marked as new, its data must<br /> be zeroed, otherwise uninitialized data in the page cache will<br /> be written.<br /> <br /> So this commit uses folio_zero_new_buffers() to zero the new<br /> buffers before -&gt;write_end().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ti-ads1298: Add NULL check in ads1298_init<br /> <br /> devm_kasprintf() can return a NULL pointer on failure. A check on the<br /> return value of such a call in ads1298_init() is missing. Add it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix the infinite loop in exfat_readdir()<br /> <br /> If the file system is corrupted so that a cluster is linked to<br /> itself in the cluster chain, and there is an unused directory<br /> entry in the cluster, &amp;#39;dentry&amp;#39; will not be incremented, causing<br /> condition &amp;#39;dentry

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix sleeping in invalid context in die()<br /> <br /> die() can be called in exception handler, and therefore cannot sleep.<br /> However, die() takes spinlock_t which can sleep with PREEMPT_RT enabled.<br /> That causes the following warning:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 285, name: mutex<br /> preempt_count: 110001, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234<br /> Hardware name: riscv-virtio,qemu (DT)<br /> Call Trace:<br /> dump_backtrace+0x1c/0x24<br /> show_stack+0x2c/0x38<br /> dump_stack_lvl+0x5a/0x72<br /> dump_stack+0x14/0x1c<br /> __might_resched+0x130/0x13a<br /> rt_spin_lock+0x2a/0x5c<br /> die+0x24/0x112<br /> do_trap_insn_illegal+0xa0/0xea<br /> _new_vmalloc_restore_context_a0+0xcc/0xd8<br /> Oops - illegal instruction [#1]<br /> <br /> Switch to use raw_spinlock_t, which does not sleep even with PREEMPT_RT<br /> enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fgraph: Add READ_ONCE() when accessing fgraph_array[]<br /> <br /> In __ftrace_return_to_handler(), a loop iterates over the fgraph_array[]<br /> elements, which are fgraph_ops. The loop checks if an element is a<br /> fgraph_stub to prevent using a fgraph_stub afterward.<br /> <br /> However, if the compiler reloads fgraph_array[] after this check, it might<br /> race with an update to fgraph_array[] that introduces a fgraph_stub. This<br /> could result in the stub being processed, but the stub contains a null<br /> "func_hash" field, leading to a NULL pointer dereference.<br /> <br /> To ensure that the gops compared against the fgraph_stub matches the gops<br /> processed later, add a READ_ONCE(). A similar patch appears in commit<br /> 63a8dfb ("function_graph: Add READ_ONCE() when accessing fgraph_array[]").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix accessing invalid dip_ctx during destroying QP<br /> <br /> If it fails to modify QP to RTR, dip_ctx will not be attached. And<br /> during detroying QP, the invalid dip_ctx pointer will be accessed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Fix max SGEs for the Work Request<br /> <br /> Gen P7 supports up to 13 SGEs for now. WQE software structure<br /> can hold only 6 now. Since the max send sge is reported as<br /> 13, the stack can give requests up to 13 SGEs. This is causing<br /> traffic failures and system crashes.<br /> <br /> Use the define for max SGE supported for variable size. This<br /> will work for both static and variable WQEs.