Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Replace rq_lock() to raw_spin_rq_lock() in scx_ops_bypass()<br /> <br /> scx_ops_bypass() iterates all CPUs to re-enqueue all the scx tasks.<br /> For each CPU, it acquires a lock using rq_lock() regardless of whether<br /> a CPU is offline or the CPU is currently running a task in a higher<br /> scheduler class (e.g., deadline). The rq_lock() is supposed to be used<br /> for online CPUs, and the use of rq_lock() may trigger an unnecessary<br /> warning in rq_pin_lock(). Therefore, replace rq_lock() to<br /> raw_spin_rq_lock() in scx_ops_bypass().<br /> <br /> Without this change, we observe the following warning:<br /> <br /> ===== START =====<br /> [ 6.615205] rq-&gt;balance_callback &amp;&amp; rq-&gt;balance_callback != &amp;balance_push_callback<br /> [ 6.615208] WARNING: CPU: 2 PID: 0 at kernel/sched/sched.h:1730 __schedule+0x1130/0x1c90<br /> ===== END =====

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: avoid NULL pointer dereference if no valid extent tree<br /> <br /> [BUG]<br /> Syzbot reported a crash with the following call trace:<br /> <br /> BTRFS info (device loop0): scrub: started on devid 1<br /> BUG: kernel NULL pointer dereference, address: 0000000000000208<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206<br /> Tainted: [O]=OOT_MODULE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022<br /> RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs]<br /> Call Trace:<br /> <br /> scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs]<br /> scrub_simple_mirror+0x175/0x260 [btrfs]<br /> scrub_stripe+0x5d4/0x6c0 [btrfs]<br /> scrub_chunk+0xbb/0x170 [btrfs]<br /> scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs]<br /> btrfs_scrub_dev+0x240/0x600 [btrfs]<br /> btrfs_ioctl+0x1dc8/0x2fa0 [btrfs]<br /> ? do_sys_openat2+0xa5/0xf0<br /> __x64_sys_ioctl+0x97/0xc0<br /> do_syscall_64+0x4f/0x120<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> [CAUSE]<br /> The reproducer is using a corrupted image where extent tree root is<br /> corrupted, thus forcing to use "rescue=all,ro" mount option to mount the<br /> image.<br /> <br /> Then it triggered a scrub, but since scrub relies on extent tree to find<br /> where the data/metadata extents are, scrub_find_fill_first_stripe()<br /> relies on an non-empty extent root.<br /> <br /> But unfortunately scrub_find_fill_first_stripe() doesn&amp;#39;t really expect<br /> an NULL pointer for extent root, it use extent_root to grab fs_info and<br /> triggered a NULL pointer dereference.<br /> <br /> [FIX]<br /> Add an extra check for a valid extent root at the beginning of<br /> scrub_find_fill_first_stripe().<br /> <br /> The new error path is introduced by 42437a6386ff ("btrfs: introduce<br /> mount option rescue=ignorebadroots"), but that&amp;#39;s pretty old, and later<br /> commit b979547513ff ("btrfs: scrub: introduce helper to find and fill<br /> sector info for a scrub_stripe") changed how we do scrub.<br /> <br /> So for kernels older than 6.6, the fix will need manual backport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdev: prevent accessing NAPI instances from another namespace<br /> <br /> The NAPI IDs were not fully exposed to user space prior to the netlink<br /> API, so they were never namespaced. The netlink API must ensure that<br /> at the very least NAPI instance belongs to the same netns as the owner<br /> of the genl sock.<br /> <br /> napi_by_id() can become static now, but it needs to move because of<br /> dev_get_by_napi_id().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: virtuser: fix missing lookup table cleanups<br /> <br /> When a virtuser device is created via configfs and the probe fails due<br /> to an incorrect lookup table, the table is not removed. This prevents<br /> subsequent probe attempts from succeeding, even if the issue is<br /> corrected, unless the device is released. Additionally, cleanup is also<br /> needed in the less likely case of platform_device_register_full()<br /> failure.<br /> <br /> Besides, a consistent memory leak in lookup_table-&gt;dev_id was spotted<br /> using kmemleak by toggling the live state between 0 and 1 with a correct<br /> lookup table.<br /> <br /> Introduce gpio_virtuser_remove_lookup_table() as the counterpart to the<br /> existing gpio_virtuser_make_lookup_table() and call it from all<br /> necessary points to ensure proper cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: dwmac-tegra: Read iommu stream id from device tree<br /> <br /> Nvidia&amp;#39;s Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be<br /> written to the MGBE_WRAP_AXI_ASID0_CTRL register.<br /> <br /> The current driver is hard coded to use MGBE0&amp;#39;s SID for all controllers.<br /> This causes softirq time outs and kernel panics when using controllers<br /> other than MGBE0.<br /> <br /> Example dmesg errors when an ethernet cable is connected to MGBE1:<br /> <br /> [ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx<br /> [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms<br /> [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.<br /> [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0<br /> [ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)<br /> [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features<br /> [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported<br /> [ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock<br /> [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode<br /> [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx<br /> [ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:<br /> [ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337<br /> [ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)<br /> [ 181.921878] Sending NMI from CPU 4 to CPUs 7:<br /> [ 181.921886] NMI backtrace for cpu 7<br /> [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6<br /> [ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024<br /> [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 181.922847] pc : handle_softirqs+0x98/0x368<br /> [ 181.922978] lr : __do_softirq+0x18/0x20<br /> [ 181.923095] sp : ffff80008003bf50<br /> [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000<br /> [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0<br /> [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70<br /> [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000<br /> [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000<br /> [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d<br /> [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160<br /> [ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74<br /> [ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1<br /> [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000<br /> [ 181.967591] Call trace:<br /> [ 181.970043] handle_softirqs+0x98/0x368 (P)<br /> [ 181.974240] __do_softirq+0x18/0x20<br /> [ 181.977743] ____do_softirq+0x14/0x28<br /> [ 181.981415] call_on_irq_stack+0x24/0x30<br /> [ 181.985180] do_softirq_own_stack+0x20/0x30<br /> [ 181.989379] __irq_exit_rcu+0x114/0x140<br /> [ 181.993142] irq_exit_rcu+0x14/0x28<br /> [ 181.996816] el1_interrupt+0x44/0xb8<br /> [ 182.000316] el1h_64_irq_handler+0x14/0x20<br /> [ 182.004343] el1h_64_irq+0x80/0x88<br /> [ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P)<br /> [ 182.012305] cpuidle_enter+0x3c/0x58<br /> [ 182.015980] cpuidle_idle_call+0x128/0x1c0<br /> [ 182.020005] do_idle+0xe0/0xf0<br /> [ 182.023155] cpu_startup_entry+0x3c/0x48<br /> [ 182.026917] secondary_start_kernel+0xdc/0x120<br /> [ 182.031379] __secondary_switched+0x74/0x78<br /> [ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.<br /> [ 212.985935] rcu: blocking rcu_node structures (internal RCU debug):<br /> [ 212.992758] Sending NMI from CPU 0 to CPUs 7:<br /> [ 212.998539] NMI backtrace for cpu 7<br /> [ 213.004304] CPU: 7 UID: 0 PI<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-blk: don&amp;#39;t keep queue frozen during system suspend<br /> <br /> Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before<br /> deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk&amp;#39;s<br /> PM callbacks. And the motivation is to drain inflight IOs before suspending.<br /> <br /> block layer&amp;#39;s queue freeze looks very handy, but it is also easy to cause<br /> deadlock, such as, any attempt to call into bio_queue_enter() may run into<br /> deadlock if the queue is frozen in current context. There are all kinds<br /> of -&gt;suspend() called in suspend context, so keeping queue frozen in the<br /> whole suspend context isn&amp;#39;t one good idea. And Marek reported lockdep<br /> warning[1] caused by virtio-blk&amp;#39;s freeze queue in virtblk_freeze().<br /> <br /> [1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/<br /> <br /> Given the motivation is to drain in-flight IOs, it can be done by calling<br /> freeze &amp; unfreeze, meantime restore to previous behavior by keeping queue<br /> quiesced during suspend.

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().