Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: fix ida_free call while not allocated<br /> <br /> In the snd_utimer_create() function, if the kasprintf() function return<br /> NULL, snd_utimer_put_id() will be called, finally use ida_free()<br /> to free the unallocated id 0.<br /> <br /> the syzkaller reported the following information:<br /> ------------[ cut here ]------------<br /> ida_free called for id=0 which is not allocated.<br /> WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014<br /> RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592<br /> Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...)<br /> RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5<br /> RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200<br /> RBP: 0000000000000000 R08: ffffffff87ba60a5 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000<br /> R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer]<br /> snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer]<br /> snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer]<br /> __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer]<br /> snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer]<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __x64_sys_ioctl+0x198/0x200 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [...]<br /> <br /> The utimer-&gt;id should be set properly before the kasprintf() function,<br /> ensures the snd_utimer_put_id() function will free the allocated id.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered<br /> <br /> If a synchronous error is detected as a result of user-space process<br /> triggering a 2-bit uncorrected error, the CPU will take a synchronous<br /> error exception such as Synchronous External Abort (SEA) on Arm64. The<br /> kernel will queue a memory_failure() work which poisons the related<br /> page, unmaps the page, and then sends a SIGBUS to the process, so that<br /> a system wide panic can be avoided.<br /> <br /> However, no memory_failure() work will be queued when abnormal<br /> synchronous errors occur. These errors can include situations like<br /> invalid PA, unexpected severity, no memory failure config support,<br /> invalid GUID section, etc. In such a case, the user-space process will<br /> trigger SEA again. This loop can potentially exceed the platform<br /> firmware threshold or even trigger a kernel hard lockup, leading to a<br /> system reboot.<br /> <br /> Fix it by performing a force kill if no memory_failure() work is queued<br /> for synchronous errors.<br /> <br /> [ rjw: Changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: remove refcounting in expectation dumpers<br /> <br /> Same pattern as previous patch: do not keep the expectation object<br /> alive via refcount, only store a cookie value and then use that<br /> as the skip hint for dump resumption.<br /> <br /> AFAICS this has the same issue as the one resolved in the conntrack<br /> dumper, when we do<br /> if (!refcount_inc_not_zero(&amp;exp-&gt;use))<br /> <br /> to increment the refcount, there is a chance that exp == last, which<br /> causes a double-increment of the refcount and subsequent memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Set .migrate_folio in gfs2_{rgrp,meta}_aops<br /> <br /> Clears up the warning added in 7ee3647243e5 ("migrate: Remove call to<br /> -&gt;writepage") that occurs in various xfstests, causing "something found<br /> in dmesg" failures.<br /> <br /> [ 341.136573] gfs2_meta_aops does not implement migrate_folio<br /> [ 341.136953] WARNING: CPU: 1 PID: 36 at mm/migrate.c:944 move_to_new_folio+0x2f8/0x300

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/smaps: fix race between smaps_hugetlb_range and migration<br /> <br /> smaps_hugetlb_range() handles the pte without holdling ptl, and may be<br /> concurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page(). <br /> The race is as follows.<br /> <br /> smaps_hugetlb_range migrate_pages<br /> huge_ptep_get<br /> remove_migration_ptes<br /> folio_unlock<br /> pfn_swap_entry_folio<br /> BUG_ON<br /> <br /> To fix it, hold ptl lock in smaps_hugetlb_range().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages<br /> <br /> Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"),<br /> we have been doing this:<br /> <br /> static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset,<br /> size_t size)<br /> [...]<br /> /* Calculate the number of bytes we need to push, for this page<br /> * specifically */<br /> size_t bytes = min_t(size_t, PAGE_SIZE - offset, size);<br /> /* If we can&amp;#39;t splice it, then copy it in, as normal */<br /> if (!sendpage_ok(page[i]))<br /> msg.msg_flags &amp;= ~MSG_SPLICE_PAGES;<br /> /* Set the bvec pointing to the page, with len $bytes */<br /> bvec_set_page(&amp;bvec, page[i], bytes, offset);<br /> /* Set the iter to $size, aka the size of the whole sendpages (!!!) */<br /> iov_iter_bvec(&amp;msg.msg_iter, ITER_SOURCE, &amp;bvec, 1, size);<br /> try_page_again:<br /> lock_sock(sk);<br /> /* Sendmsg with $size size (!!!) */<br /> rv = tcp_sendmsg_locked(sk, &amp;msg, size);<br /> <br /> This means we&amp;#39;ve been sending oversized iov_iters and tcp_sendmsg calls<br /> for a while. This has a been a benign bug because sendpage_ok() always<br /> returned true. With the recent slab allocator changes being slowly<br /> introduced into next (that disallow sendpage on large kmalloc<br /> allocations), we have recently hit out-of-bounds crashes, due to slight<br /> differences in iov_iter behavior between the MSG_SPLICE_PAGES and<br /> "regular" copy paths:<br /> <br /> (MSG_SPLICE_PAGES)<br /> skb_splice_from_iter<br /> iov_iter_extract_pages<br /> iov_iter_extract_bvec_pages<br /> uses i-&gt;nr_segs to correctly stop in its tracks before OoB&amp;#39;ing everywhere<br /> skb_splice_from_iter gets a "short" read<br /> <br /> (!MSG_SPLICE_PAGES)<br /> skb_copy_to_page_nocache copy=iov_iter_count<br /> [...]<br /> copy_from_iter<br /> /* this doesn&amp;#39;t help */<br /> if (unlikely(iter-&gt;count count;<br /> iterate_bvec<br /> ... and we run off the bvecs<br /> <br /> Fix this by properly setting the iov_iter&amp;#39;s byte count, plus sending the<br /> correct byte count to tcp_sendmsg_locked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: Prevent file descriptor table allocations exceeding INT_MAX<br /> <br /> When sysctl_nr_open is set to a very high value (for example, 1073741816<br /> as set by systemd), processes attempting to use file descriptors near<br /> the limit can trigger massive memory allocation attempts that exceed<br /> INT_MAX, resulting in a WARNING in mm/slub.c:<br /> <br /> WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288<br /> <br /> This happens because kvmalloc_array() and kvmalloc() check if the<br /> requested size exceeds INT_MAX and emit a warning when the allocation is<br /> not flagged with __GFP_NOWARN.<br /> <br /> Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a<br /> process calls dup2(oldfd, 1073741880), the kernel attempts to allocate:<br /> - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes<br /> - Multiple bitmaps: ~400MB<br /> - Total allocation size: &gt; 8GB (exceeding INT_MAX = 2,147,483,647)<br /> <br /> Reproducer:<br /> 1. Set /proc/sys/fs/nr_open to 1073741816:<br /> # echo 1073741816 &gt; /proc/sys/fs/nr_open<br /> <br /> 2. Run a program that uses a high file descriptor:<br /> #include <br /> #include <br /> <br /> int main() {<br /> struct rlimit rlim = {1073741824, 1073741824};<br /> setrlimit(RLIMIT_NOFILE, &amp;rlim);<br /> dup2(2, 1073741880); // Triggers the warning<br /> return 0;<br /> }<br /> <br /> 3. Observe WARNING in dmesg at mm/slub.c:5027<br /> <br /> systemd commit a8b627a introduced automatic bumping of fs.nr_open to the<br /> maximum possible value. The rationale was that systems with memory<br /> control groups (memcg) no longer need separate file descriptor limits<br /> since memory is properly accounted. However, this change overlooked<br /> that:<br /> <br /> 1. The kernel&amp;#39;s allocation functions still enforce INT_MAX as a maximum<br /> size regardless of memcg accounting<br /> 2. Programs and tests that legitimately test file descriptor limits can<br /> inadvertently trigger massive allocations<br /> 3. The resulting allocations (&gt;8GB) are impractical and will always fail<br /> <br /> systemd&amp;#39;s algorithm starts with INT_MAX and keeps halving the value<br /> until the kernel accepts it. On most systems, this results in nr_open<br /> being set to 1073741816 (0x3ffffff8), which is just under 1GB of file<br /> descriptors.<br /> <br /> While processes rarely use file descriptors near this limit in normal<br /> operation, certain selftests (like<br /> tools/testing/selftests/core/unshare_test.c) and programs that test file<br /> descriptor limits can trigger this issue.<br /> <br /> Fix this by adding a check in alloc_fdtable() to ensure the requested<br /> allocation size does not exceed INT_MAX. This causes the operation to<br /> fail with -EMFILE instead of triggering a kernel warning and avoids the<br /> impractical &gt;8GB memory allocation request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Validate UAC3 cluster segment descriptors<br /> <br /> UAC3 class segment descriptors need to be verified whether their sizes<br /> match with the declared lengths and whether they fit with the<br /> allocated buffer sizes, too. Otherwise malicious firmware may lead to<br /> the unexpected OOB accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: qgroup: fix race between quota disable and quota rescan ioctl<br /> <br /> There&amp;#39;s a race between a task disabling quotas and another running the<br /> rescan ioctl that can result in a use-after-free of qgroup records from<br /> the fs_info-&gt;qgroup_tree rbtree.<br /> <br /> This happens as follows:<br /> <br /> 1) Task A enters btrfs_ioctl_quota_rescan() -&gt; btrfs_qgroup_rescan();<br /> <br /> 2) Task B enters btrfs_quota_disable() and calls<br /> btrfs_qgroup_wait_for_completion(), which does nothing because at that<br /> point fs_info-&gt;qgroup_rescan_running is false (it wasn&amp;#39;t set yet by<br /> task A);<br /> <br /> 3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups<br /> from fs_info-&gt;qgroup_tree without taking the lock fs_info-&gt;qgroup_lock;<br /> <br /> 4) Task A enters qgroup_rescan_zero_tracking() which starts iterating<br /> the fs_info-&gt;qgroup_tree tree while holding fs_info-&gt;qgroup_lock,<br /> but task B is freeing qgroup records from that tree without holding<br /> the lock, resulting in a use-after-free.<br /> <br /> Fix this by taking fs_info-&gt;qgroup_lock at btrfs_free_qgroup_config().<br /> Also at btrfs_qgroup_rescan() don&amp;#39;t start the rescan worker if quotas<br /> were already disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: core: config: Prevent OOB read in SS endpoint companion parsing<br /> <br /> usb_parse_ss_endpoint_companion() checks descriptor type before length,<br /> enabling a potentially odd read outside of the buffer size.<br /> <br /> Fix this up by checking the size first before looking at any of the<br /> fields in the descriptor.

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/msm: Add error handling for krealloc in metadata setup<br /> <br /> Function msm_ioctl_gem_info_set_metadata() now checks for krealloc<br /> failure and returns -ENOMEM, avoiding potential NULL pointer dereference.<br /> Explicitly avoids __GFP_NOFAIL due to deadlock risks and allocation constraints.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/661235/