Vulnerabilities

Buffer Overflow vulnerability in giflib v.5.2.2 allows a remote attacker to cause a denial of service via the EGifGCBToExtension overwriting an existing Graphic Control Extension block without validating its allocated size.

Dell Integrated Dell Remote Access Controller 9, 14G versions prior to 7.00.00.181, 15G and 16G versions prior to 7.20.10.50 and Dell Integrated Dell Remote Access Controller 10, 17G versions prior to 1.20.25.00, contain a Process Control vulnerability. A high privileged attacker with adjacent network access could potentially exploit this vulnerability, leading to code execution.

Dell Integrated Dell Remote Access Controller 9, 14G versions prior to 7.00.00.174, 15G and 16G versions prior to 7.10.90.00, contain an Exposure of Sensitive System Information Due to Uncleared Debug Information vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to information disclosure.

nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. Prior to version 1.68.1, the nghttp2 library stops reading the incoming data when user facing public API `nghttp2_session_terminate_session` or `nghttp2_session_terminate_session2` is called by the application. They might be called internally by the library when it detects the situation that is subject to connection error. Due to the missing internal state validation, the library keeps reading the rest of the data after one of those APIs is called. Then receiving a malformed frame that causes FRAME_SIZE_ERROR causes assertion failure. nghttp2 v1.68.1 adds missing state validation to avoid assertion failure. No known workarounds are available.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks<br /> <br /> As Paolo said earlier [1]:<br /> <br /> "Since the blamed commit below, classify can return TC_ACT_CONSUMED while<br /> the current skb being held by the defragmentation engine. As reported by<br /> GangMin Kim, if such packet is that may cause a UaF when the defrag engine<br /> later on tries to tuch again such packet."<br /> <br /> act_ct was never meant to be used in the egress path, however some users<br /> are attaching it to egress today [2]. Attempting to reach a middle<br /> ground, we noticed that, while most qdiscs are not handling<br /> TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we<br /> address the issue by only allowing act_ct to bind to clsact/ingress<br /> qdiscs and shared blocks. That way it&amp;#39;s still possible to attach act_ct to<br /> egress (albeit only with clsact).<br /> <br /> [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/<br /> [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "drm/amd: Check if ASPM is enabled from PCIe subsystem"<br /> <br /> This reverts commit 7294863a6f01248d72b61d38478978d638641bee.<br /> <br /> This commit was erroneously applied again after commit 0ab5d711ec74<br /> ("drm/amd: Refactor `amdgpu_aspm` to be evaluated per device")<br /> removed it, leading to very hard to debug crashes, when used with a system with two<br /> AMD GPUs of which only one supports ASPM.<br /> <br /> (cherry picked from commit 97a9689300eb2b393ba5efc17c8e5db835917080)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on node footer in {read,write}_end_io<br /> <br /> -----------[ cut here ]------------<br /> kernel BUG at fs/f2fs/data.c:358!<br /> Call Trace:<br /> <br /> blk_update_request+0x5eb/0xe70 block/blk-mq.c:987<br /> blk_mq_end_request+0x3e/0x70 block/blk-mq.c:1149<br /> blk_complete_reqs block/blk-mq.c:1224 [inline]<br /> blk_done_softirq+0x107/0x160 block/blk-mq.c:1229<br /> handle_softirqs+0x283/0x870 kernel/softirq.c:579<br /> __do_softirq kernel/softirq.c:613 [inline]<br /> invoke_softirq kernel/softirq.c:453 [inline]<br /> __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680<br /> irq_exit_rcu+0x9/0x30 kernel/softirq.c:696<br /> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1050 [inline]<br /> sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1050<br /> <br /> <br /> In f2fs_write_end_io(), it detects there is inconsistency in between<br /> node page index (nid) and footer.nid of node page.<br /> <br /> If footer of node page is corrupted in fuzzed image, then we load corrupted<br /> node page w/ async method, e.g. f2fs_ra_node_pages() or f2fs_ra_node_page(),<br /> in where we won&amp;#39;t do sanity check on node footer, once node page becomes<br /> dirty, we will encounter this bug after node page writeback.

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.