Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()<br /> <br /> ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0<br /> <br /> ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause<br /> NULL pointer dereference later.<br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: bcm2835: Fix timeout during suspend mode<br /> <br /> During noirq suspend phase the Raspberry Pi power driver suffer of<br /> firmware property timeouts. The reason is that the IRQ of the underlying<br /> BCM2835 mailbox is disabled and rpi_firmware_property_list() will always<br /> run into a timeout [1].<br /> <br /> Since the VideoCore side isn&amp;#39;t consider as a wakeup source, set the<br /> IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled<br /> during suspend-resume cycle.<br /> <br /> [1]<br /> PM: late suspend of devices complete after 1.754 msecs<br /> WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128<br /> rpi_firmware_property_list+0x204/0x22c<br /> Firmware transaction 0x00028001 timeout<br /> Modules linked in:<br /> CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17<br /> Hardware name: BCM2835<br /> Call trace:<br /> unwind_backtrace from show_stack+0x18/0x1c<br /> show_stack from dump_stack_lvl+0x34/0x44<br /> dump_stack_lvl from __warn+0x88/0xec<br /> __warn from warn_slowpath_fmt+0x7c/0xb0<br /> warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c<br /> rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c<br /> rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0<br /> rpi_firmware_set_power from _genpd_power_off+0xe4/0x148<br /> _genpd_power_off from genpd_sync_power_off+0x7c/0x11c<br /> genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0<br /> genpd_finish_suspend from dpm_run_callback+0x78/0xd0<br /> dpm_run_callback from device_suspend_noirq+0xc0/0x238<br /> device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168<br /> dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac<br /> suspend_devices_and_enter from pm_suspend+0x254/0x2e4<br /> pm_suspend from state_store+0xa8/0xd4<br /> state_store from kernfs_fop_write_iter+0x154/0x1a0<br /> kernfs_fop_write_iter from vfs_write+0x12c/0x184<br /> vfs_write from ksys_write+0x78/0xc0<br /> ksys_write from ret_fast_syscall+0x0/0x54<br /> Exception stack(0xcc93dfa8 to 0xcc93dff0)<br /> [...]<br /> PM: noirq suspend of devices complete after 3095.584 msecs

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix memfd_pin_folios free_huge_pages leak<br /> <br /> memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages<br /> if the pages were not already faulted in, because the folio refcount for<br /> pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios<br /> needs another folio_put to undo the folio_try_get below:<br /> <br /> memfd_alloc_folio()<br /> alloc_hugetlb_folio_nodemask()<br /> dequeue_hugetlb_folio_nodemask()<br /> dequeue_hugetlb_folio_node_exact()<br /> folio_ref_unfreeze(folio, 1); ; adds 1 refcount<br /> folio_try_get() ; adds 1 refcount<br /> hugetlb_add_to_page_cache() ; adds 512 refcount (on x86)<br /> <br /> With the fix, after memfd_pin_folios + unpin_folios, the refcount for the<br /> (unfaulted) page is 512, which is correct, as the refcount for a faulted<br /> unpinned page is 513.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: remove unreasonable unlock in ocfs2_read_blocks<br /> <br /> Patch series "Misc fixes for ocfs2_read_blocks", v5.<br /> <br /> This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix<br /> the issue reported by syzbot, which detects bad unlock balance in<br /> ocfs2_read_blocks(). The second patch fixes an issue reported by Heming<br /> Zhao when reviewing above fix.<br /> <br /> <br /> This patch (of 2):<br /> <br /> There was a lock release before exiting, so remove the unreasonable unlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: cancel dqi_sync_work before freeing oinfo<br /> <br /> ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the<br /> end, if error occurs after successfully reading global quota, it will<br /> trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:<br /> <br /> ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c<br /> <br /> This reports that there is an active delayed work when freeing oinfo in<br /> error handling, so cancel dqi_sync_work first. BTW, return status instead<br /> of -1 when .read_file_info fails.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: filesystems without casefold feature cannot be mounted with siphash<br /> <br /> When mounting the ext4 filesystem, if the default hash version is set to<br /> DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix index out of bounds in DCN30 color transformation<br /> <br /> This commit addresses a potential index out of bounds issue in the<br /> `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color<br /> management module. The issue could occur when the index &amp;#39;i&amp;#39; exceeds the<br /> number of transfer function points (TRANSFER_FUNC_POINTS).<br /> <br /> The fix adds a check to ensure &amp;#39;i&amp;#39; is within bounds before accessing the<br /> transfer function points. If &amp;#39;i&amp;#39; is out of bounds, the function returns<br /> false to indicate an error.<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow &amp;#39;output_tf-&gt;tf_pts.red&amp;#39; 1025 tf_pts.green&amp;#39; 1025 tf_pts.blue&amp;#39; 1025

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Implement bounds check for stream encoder creation in DCN401<br /> <br /> &amp;#39;stream_enc_regs&amp;#39; array is an array of dcn10_stream_enc_registers<br /> structures. The array is initialized with four elements, corresponding<br /> to the four calls to stream_enc_regs() in the array initializer. This<br /> means that valid indices for this array are 0, 1, 2, and 3.<br /> <br /> The error message &amp;#39;stream_enc_regs&amp;#39; 4

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ncsi: Disable the ncsi work before freeing the associated structure<br /> <br /> The work function can run after the ncsi device is freed, resulting<br /> in use-after-free bugs or kernel panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: do not assume bh is held in ppp_channel_bridge_input()<br /> <br /> Networking receive path is usually handled from BH handler.<br /> However, some protocols need to acquire the socket lock, and<br /> packets might be stored in the socket backlog is the socket was<br /> owned by a user process.<br /> <br /> In this case, release_sock(), __release_sock(), and sk_backlog_rcv()<br /> might call the sk-&gt;sk_backlog_rcv() handler in process context.<br /> <br /> sybot caught ppp was not considering this case in<br /> ppp_channel_bridge_input() :<br /> <br /> WARNING: inconsistent lock state<br /> 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted<br /> --------------------------------<br /> inconsistent {SOFTIRQ-ON-W} -&gt; {IN-SOFTIRQ-W} usage.<br /> ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes:<br /> ffff0000db7f11e0 (&amp;pch-&gt;downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]<br /> ffff0000db7f11e0 (&amp;pch-&gt;downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]<br /> ffff0000db7f11e0 (&amp;pch-&gt;downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304<br /> {SOFTIRQ-ON-W} state was registered at:<br /> lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759<br /> __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]<br /> _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154<br /> spin_lock include/linux/spinlock.h:351 [inline]<br /> ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]<br /> ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304<br /> pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379<br /> sk_backlog_rcv include/net/sock.h:1111 [inline]<br /> __release_sock+0x1a8/0x3d8 net/core/sock.c:3004<br /> release_sock+0x68/0x1b8 net/core/sock.c:3558<br /> pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> __sys_sendto+0x374/0x4f4 net/socket.c:2204<br /> __do_sys_sendto net/socket.c:2216 [inline]<br /> __se_sys_sendto net/socket.c:2212 [inline]<br /> __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712<br /> el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598<br /> irq event stamp: 282914<br /> hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline]<br /> hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194<br /> hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]<br /> hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162<br /> softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline]<br /> softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582<br /> softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;pch-&gt;downl);<br /> <br /> lock(&amp;pch-&gt;downl);<br /> <br /> *** DEADLOCK ***<br /> <br /> 1 lock held by ksoftirqd/1/24:<br /> #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325<br /> <br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Call trace:<br /> dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326<br /> __dump_sta<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: test for not too small csum_start in virtio_net_hdr_to_skb()<br /> <br /> syzbot was able to trigger this warning [1], after injecting a<br /> malicious packet through af_packet, setting skb-&gt;csum_start and thus<br /> the transport header to an incorrect value.<br /> <br /> We can at least make sure the transport header is after<br /> the end of the network header (with a estimated minimal size).<br /> <br /> [1]<br /> [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0<br /> mac=(-1,-1) mac_len=0 net=(16,-6) trans=10<br /> shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0))<br /> csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0)<br /> hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0<br /> priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0<br /> encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)<br /> [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9<br /> [ 67.877764] sk family=17 type=3 proto=0<br /> [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00<br /> [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02<br /> [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00<br /> [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e<br /> [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00<br /> [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.887384] skb frag: 00000100: 00 00<br /> [ 67.887878] ------------[ cut here ]------------<br /> [ 67.887908] offset (-6) &gt;= skb_headlen() (14)<br /> [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs<br /> [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011<br /> [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.891043] Call Trace:<br /> [ 67.891173] <br /> [ 67.891274] ? __warn (kernel/panic.c:741)<br /> [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219)<br /> [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239)<br /> [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))<br /> [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)<br /> [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1))<br /> [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne<br /> ---truncated---