Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error<br /> <br /> In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()<br /> to recover some journal space. But if an error occurs while executing<br /> jbd2_cleanup_journal_tail() (e.g., an EIO), we don&amp;#39;t stop waiting for free<br /> space right away, we try other branches, and if j_committing_transaction<br /> is NULL (i.e., the tid is 0), we will get the following complain:<br /> <br /> ============================================<br /> JBD2: I/O error when updating journal superblock for sdd-8.<br /> __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available<br /> __jbd2_log_wait_for_space: no way to get more journal space in sdd-8<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0<br /> Modules linked in:<br /> CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1<br /> RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0<br /> Call Trace:<br /> <br /> add_transaction_credits+0x5d1/0x5e0<br /> start_this_handle+0x1ef/0x6a0<br /> jbd2__journal_start+0x18b/0x340<br /> ext4_dirty_inode+0x5d/0xb0<br /> __mark_inode_dirty+0xe4/0x5d0<br /> generic_update_time+0x60/0x70<br /> [...]<br /> ============================================<br /> <br /> So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to<br /> clean up at the moment, continue to try to reclaim free space in other ways.<br /> <br /> Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt<br /> when updating journal superblock fails") to make jbd2_cleanup_journal_tail<br /> return the correct error code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix timer use-after-free on failed mount<br /> <br /> Syzbot has found an ODEBUG bug in ext4_fill_super<br /> <br /> The del_timer_sync function cancels the s_err_report timer,<br /> which reminds about filesystem errors daily. We should<br /> guarantee the timer is no longer active before kfree(sbi).<br /> <br /> When filesystem mounting fails, the flow goes to failed_mount3,<br /> where an error occurs when ext4_stop_mmpd is called, causing<br /> a read I/O failure. This triggers the ext4_handle_error function<br /> that ultimately re-arms the timer,<br /> leaving the s_err_report timer active before kfree(sbi) is called.<br /> <br /> Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: ar0521: Use cansleep version of gpiod_set_value()<br /> <br /> If we use GPIO reset from I2C port expander, we must use *_cansleep()<br /> variant of GPIO functions.<br /> This was not done in ar0521_power_on()/ar0521_power_off() functions.<br /> Let&amp;#39;s fix that.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c<br /> Modules linked in:<br /> CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53<br /> Hardware name: Diasom DS-RK3568-SOM-EVB (DT)<br /> Workqueue: events_unbound deferred_probe_work_func<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : gpiod_set_value+0x74/0x7c<br /> lr : ar0521_power_on+0xcc/0x290<br /> sp : ffffff8001d7ab70<br /> x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000<br /> x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088<br /> x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088<br /> x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80<br /> x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000<br /> x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930<br /> x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0<br /> x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780<br /> x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001<br /> Call trace:<br /> gpiod_set_value+0x74/0x7c<br /> ar0521_power_on+0xcc/0x290<br /> ...

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 /> 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.

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 /> 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 /> 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 /> 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---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice<br /> <br /> The km.state is not checked in driver&amp;#39;s delayed work. When<br /> xfrm_state_check_expire() is called, the state can be reset to<br /> XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This<br /> happens when xfrm state is deleted, but not freed yet. As<br /> __xfrm_state_delete() is called again in xfrm timer, the following<br /> crash occurs.<br /> <br /> To fix this issue, skip xfrm_state_check_expire() if km.state is not<br /> XFRM_STATE_VALID.<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP<br /> CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core]<br /> RIP: 0010:__xfrm_state_delete+0x3d/0x1b0<br /> Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48<br /> RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246<br /> RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036<br /> RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980<br /> RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000<br /> R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246<br /> R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400<br /> FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? die_addr+0x33/0x90<br /> ? exc_general_protection+0x1a2/0x390<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? __xfrm_state_delete+0x3d/0x1b0<br /> ? __xfrm_state_delete+0x2f/0x1b0<br /> xfrm_timer_handler+0x174/0x350<br /> ? __xfrm_state_delete+0x1b0/0x1b0<br /> __hrtimer_run_queues+0x121/0x270<br /> hrtimer_run_softirq+0x88/0xd0<br /> handle_softirqs+0xcc/0x270<br /> do_softirq+0x3c/0x50<br /> <br /> <br /> __local_bh_enable_ip+0x47/0x50<br /> mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core]<br /> process_one_work+0x137/0x2d0<br /> worker_thread+0x28d/0x3a0<br /> ? rescuer_thread+0x480/0x480<br /> kthread+0xb8/0xe0<br /> ? kthread_park+0x80/0x80<br /> ret_from_fork+0x2d/0x50<br /> ? kthread_park+0x80/0x80<br /> ret_from_fork_asm+0x11/0x20<br />