Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: rivafb: fix divide error in nv3_arb()<br /> <br /> A userspace program can trigger the RIVA NV3 arbitration code by calling<br /> the FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driver<br /> recomputes FIFO arbitration parameters in nv3_arb(), using state-&gt;mclk_khz<br /> (derived from the PRAMDAC MCLK PLL) as a divisor without validating it<br /> first.<br /> <br /> In a normal setup, state-&gt;mclk_khz is provided by the real hardware and is<br /> non-zero. However, an attacker can construct a malicious or misconfigured<br /> device (e.g. a crafted/emulated PCI device) that exposes a bogus PLL<br /> configuration, causing state-&gt;mclk_khz to become zero. Once<br /> nv3_get_param() calls nv3_arb(), the division by state-&gt;mclk_khz in the gns<br /> calculation causes a divide error and crashes the kernel.<br /> <br /> Fix this by checking whether state-&gt;mclk_khz is zero and bailing out before<br /> doing the division.<br /> <br /> The following log reveals it:<br /> <br /> rivafb: setting virtual Y resolution to 2184<br /> divide error: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline]<br /> RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546<br /> Call Trace:<br /> nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603<br /> nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline]<br /> CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246<br /> riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779<br /> rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196<br /> fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033<br /> do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109<br /> fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188<br /> __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes<br /> <br /> During SPO tests, when mounting F2FS, an -EINVAL error was returned from<br /> f2fs_recover_inode_page. The issue occurred under the following scenario<br /> <br /> Thread A Thread B<br /> f2fs_ioc_commit_atomic_write<br /> - f2fs_do_sync_file // atomic = true<br /> - f2fs_fsync_node_pages<br /> : last_folio = inode folio<br /> : schedule before folio_lock(last_folio) f2fs_write_checkpoint<br /> - block_operations// writeback last_folio<br /> - schedule before f2fs_flush_nat_entries<br /> : set_fsync_mark(last_folio, 1)<br /> : set_dentry_mark(last_folio, 1)<br /> : folio_mark_dirty(last_folio)<br /> - __write_node_folio(last_folio)<br /> : f2fs_down_read(&amp;sbi-&gt;node_write)//block<br /> - f2fs_flush_nat_entries<br /> : {struct nat_entry}-&gt;flag |= BIT(IS_CHECKPOINTED)<br /> - unblock_operations<br /> : f2fs_up_write(&amp;sbi-&gt;node_write)<br /> f2fs_write_checkpoint//return<br /> : f2fs_do_write_node_page()<br /> f2fs_ioc_commit_atomic_write//return<br /> SPO<br /> <br /> Thread A calls f2fs_need_dentry_mark(sbi, ino), and the last_folio has<br /> already been written once. However, the {struct nat_entry}-&gt;flag did not<br /> have the IS_CHECKPOINTED set, causing set_dentry_mark(last_folio, 1) and<br /> write last_folio again after Thread B finishes f2fs_write_checkpoint.<br /> <br /> After SPO and reboot, it was detected that {struct node_info}-&gt;blk_addr<br /> was not NULL_ADDR because Thread B successfully write the checkpoint.<br /> <br /> This issue only occurs in atomic write scenarios. For regular file<br /> fsync operations, the folio must be dirty. If<br /> block_operations-&gt;f2fs_sync_node_pages successfully submit the folio<br /> write, this path will not be executed. Otherwise, the<br /> f2fs_write_checkpoint will need to wait for the folio write submission<br /> to complete, as sbi-&gt;nr_pages[F2FS_DIRTY_NODES] &gt; 0. Therefore, the<br /> situation where f2fs_need_dentry_mark checks that the {struct<br /> nat_entry}-&gt;flag /wo the IS_CHECKPOINTED flag, but the folio write has<br /> already been submitted, will not occur.<br /> <br /> Therefore, for atomic file fsync, sbi-&gt;node_write should be acquired<br /> through __write_node_folio to ensure that the IS_CHECKPOINTED flag<br /> correctly indicates that the checkpoint write has been completed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix unprivileged local user can do privileged policy management<br /> <br /> An unprivileged local user can load, replace, and remove profiles by<br /> opening the apparmorfs interfaces, via a confused deputy attack, by<br /> passing the opened fd to a privileged process, and getting the<br /> privileged process to write to the interface.<br /> <br /> This does require a privileged target that can be manipulated to do<br /> the write for the unprivileged process, but once such access is<br /> achieved full policy management is possible and all the possible<br /> implications that implies: removing confinement, DoS of system or<br /> target applications by denying all execution, by-passing the<br /> unprivileged user namespace restriction, to exploiting kernel bugs for<br /> a local privilege escalation.<br /> <br /> The policy management interface can not have its permissions simply<br /> changed from 0666 to 0600 because non-root processes need to be able<br /> to load policy to different policy namespaces.<br /> <br /> Instead ensure the task writing the interface has privileges that<br /> are a subset of the task that opened the interface. This is already<br /> done via policy for confined processes, but unconfined can delegate<br /> access to the opened fd, by-passing the usual policy check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: validate DFA start states are in bounds in unpack_pdb<br /> <br /> Start states are read from untrusted data and used as indexes into the<br /> DFA state tables. The aa_dfa_next() function call in unpack_pdb() will<br /> access dfa-&gt;tables[YYTD_ID_BASE][start], and if the start state exceeds<br /> the number of states in the DFA, this results in an out-of-bound read.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360<br /> Read of size 4 at addr ffff88811956fb90 by task su/1097<br /> ...<br /> <br /> Reject policies with out-of-bounds start states during unpacking<br /> to prevent the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: liquidio: Initialize netdev pointer before queue setup<br /> <br /> In setup_nic_devices(), the netdev is allocated using alloc_etherdev_mq().<br /> However, the pointer to this structure is stored in oct-&gt;props[i].netdev<br /> only after the calls to netif_set_real_num_rx_queues() and<br /> netif_set_real_num_tx_queues().<br /> <br /> If either of these functions fails, setup_nic_devices() returns an error<br /> without freeing the allocated netdev. Since oct-&gt;props[i].netdev is still<br /> NULL at this point, the cleanup function liquidio_destroy_nic_device()<br /> will fail to find and free the netdev, resulting in a memory leak.<br /> <br /> Fix this by initializing oct-&gt;props[i].netdev before calling the queue<br /> setup functions. This ensures that the netdev is properly accessible for<br /> cleanup in case of errors.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rw: free potentially allocated iovec on cache put failure<br /> <br /> If a read/write request goes through io_req_rw_cleanup() and has an<br /> allocated iovec attached and fails to put to the rw_cache, then it may<br /> end up with an unaccounted iovec pointer. Have io_rw_recycle() return<br /> whether it recycled the request or not, and use that to gauge whether to<br /> free a potential iovec or not.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap: maple: free entry on mas_store_gfp() failure<br /> <br /> regcache_maple_write() allocates a new block (&amp;#39;entry&amp;#39;) to merge<br /> adjacent ranges and then stores it with mas_store_gfp().<br /> When mas_store_gfp() fails, the new &amp;#39;entry&amp;#39; remains allocated and<br /> is never freed, leaking memory.<br /> <br /> Free &amp;#39;entry&amp;#39; on the failure path; on success continue freeing the<br /> replaced neighbor blocks (&amp;#39;lower&amp;#39;, &amp;#39;upper&amp;#39;).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-fc: release admin tagset if init fails<br /> <br /> nvme_fabrics creates an NVMe/FC controller in following path:<br /> <br /> nvmf_dev_write()<br /> -&gt; nvmf_create_ctrl()<br /> -&gt; nvme_fc_create_ctrl()<br /> -&gt; nvme_fc_init_ctrl()<br /> <br /> nvme_fc_init_ctrl() allocates the admin blk-mq resources right after<br /> nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing<br /> the controller state, scheduling connect work, etc.), we jump to the<br /> fail_ctrl path, which tears down the controller references but never<br /> frees the admin queue/tag set. The leaked blk-mq allocations match the<br /> kmemleak report seen during blktests nvme/fc.<br /> <br /> Check ctrl-&gt;ctrl.admin_tagset in the fail_ctrl path and call<br /> nvme_remove_admin_tag_set() when it is set so that all admin queue<br /> allocations are reclaimed whenever controller setup aborts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: Fix stats report corruption on queue count change<br /> <br /> The driver and the NIC share a region in memory for stats reporting.<br /> The NIC calculates its offset into this region based on the total size<br /> of the stats region and the size of the NIC&amp;#39;s stats.<br /> <br /> When the number of queues is changed, the driver&amp;#39;s stats region is<br /> resized. If the queue count is increased, the NIC can write past<br /> the end of the allocated stats region, causing memory corruption.<br /> If the queue count is decreased, there is a gap between the driver<br /> and NIC stats, leading to incorrect stats reporting.<br /> <br /> This change fixes the issue by allocating stats region with maximum<br /> size, and the offset calculation for NIC stats is changed to match<br /> with the calculation of the NIC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix page array leak<br /> <br /> d9f595b9a65e ("io_uring/zcrx: fix leaking pages on sg init fail") fixed<br /> a page leakage but didn&amp;#39;t free the page array, release it as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: only call xf{array,blob}_destroy if we have a valid pointer<br /> <br /> Only call the xfarray and xfblob destructor if we have a valid pointer,<br /> and be sure to null out that pointer afterwards. Note that this patch<br /> fixes a large number of commits, most of which were merged between 6.9<br /> and 6.10.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gro: fix outer network offset<br /> <br /> The udp GRO complete stage assumes that all the packets inserted the RX<br /> have the `encapsulation` flag zeroed. Such assumption is not true, as a<br /> few H/W NICs can set such flag when H/W offloading the checksum for<br /> an UDP encapsulated traffic, the tun driver can inject GSO packets with<br /> UDP encapsulation and the problematic layout can also be created via<br /> a veth based setup.<br /> <br /> Due to the above, in the problematic scenarios, udp4_gro_complete() uses<br /> the wrong network offset (inner instead of outer) to compute the outer<br /> UDP header pseudo checksum, leading to csum validation errors later on<br /> in packet processing.<br /> <br /> Address the issue always clearing the encapsulation flag at GRO completion<br /> time. Such flag will be set again as needed for encapsulated packets by<br /> udp_gro_complete().