Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: fix tcp fraglist segmentation after pull from frag_list<br /> <br /> Detect tcp gso fraglist skbs with corrupted geometry (see below) and<br /> pass these to skb_segment instead of skb_segment_list, as the first<br /> can segment them correctly.<br /> <br /> Valid SKB_GSO_FRAGLIST skbs<br /> - consist of two or more segments<br /> - the head_skb holds the protocol headers plus first gso_size<br /> - one or more frag_list skbs hold exactly one segment<br /> - all but the last must be gso_size<br /> <br /> Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can<br /> modify these skbs, breaking these invariants.<br /> <br /> In extreme cases they pull all data into skb linear. For TCP, this<br /> causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at<br /> tcp_hdr(seg-&gt;next).<br /> <br /> Detect invalid geometry due to pull, by checking head_skb size.<br /> Don&amp;#39;t just drop, as this may blackhole a destination. Convert to be<br /> able to pass to regular skb_segment.<br /> <br /> Approach and description based on a patch by Willem de Bruijn.

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.

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 /> 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 /> 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 /> ocfs2: reserve space for inline xattr before attaching reflink tree<br /> <br /> One of our customers reported a crash and a corrupted ocfs2 filesystem. <br /> The crash was due to the detection of corruption. Upon troubleshooting,<br /> the fsck -fn output showed the below corruption<br /> <br /> [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,<br /> but fsck believes the largest valid value is 227. Clamp the next record value? n<br /> <br /> The stat output from the debugfs.ocfs2 showed the following corruption<br /> where the "Next Free Rec:" had overshot the "Count:" in the root metadata<br /> block.<br /> <br /> Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856)<br /> FS Generation: 904309833 (0x35e6ac49)<br /> CRC32: 00000000 ECC: 0000<br /> Type: Regular Attr: 0x0 Flags: Valid<br /> Dynamic Features: (0x16) HasXattr InlineXattr Refcounted<br /> Extended Attributes Block: 0 Extended Attributes Inline Size: 256<br /> User: 0 (root) Group: 0 (root) Size: 281320357888<br /> Links: 1 Clusters: 141738<br /> ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024<br /> atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024<br /> mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024<br /> dtime: 0x0 -- Wed Dec 31 17:00:00 1969<br /> Refcount Block: 2777346<br /> Last Extblk: 2886943 Orphan Slot: 0<br /> Sub Alloc Slot: 0 Sub Alloc Bit: 14<br /> Tree Depth: 1 Count: 227 Next Free Rec: 230<br /> ## Offset Clusters Block#<br /> 0 0 2310 2776351<br /> 1 2310 2139 2777375<br /> 2 4449 1221 2778399<br /> 3 5670 731 2779423<br /> 4 6401 566 2780447<br /> ....... .... .......<br /> ....... .... .......<br /> <br /> The issue was in the reflink workfow while reserving space for inline<br /> xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the<br /> time this function is called the reflink tree is already recreated at the<br /> destination inode from the source inode. At this point, this function<br /> reserves space for inline xattrs at the destination inode without even<br /> checking if there is space at the root metadata block. It simply reduces<br /> the l_count from 243 to 227 thereby making space of 256 bytes for inline<br /> xattr whereas the inode already has extents beyond this index (in this<br /> case up to 230), thereby causing corruption.<br /> <br /> The fix for this is to reserve space for inline metadata at the destination<br /> inode before the reflink tree gets recreated. The customer has verified the<br /> fix.

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.