Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().<br /> <br /> syzkaller triggered the warning [0] in udp_v4_early_demux().<br /> <br /> In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount<br /> of the looked-up sk and use sock_pfree() as skb-&gt;destructor, so we check<br /> SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace<br /> period.<br /> <br /> Currently, SOCK_RCU_FREE is flagged for a bound socket after being put<br /> into the hash table. Moreover, the SOCK_RCU_FREE check is done too early<br /> in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race<br /> window:<br /> <br /> CPU1 CPU2<br /> ---- ----<br /> udp_v4_early_demux() udp_lib_get_port()<br /> | |- hlist_add_head_rcu()<br /> |- sk = __udp4_lib_demux_lookup() |<br /> |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));<br /> `- sock_set_flag(sk, SOCK_RCU_FREE)<br /> <br /> We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:<br /> set SOCK_RCU_FREE before inserting socket into hashtable").<br /> <br /> Let&amp;#39;s apply the same fix for UDP.<br /> <br /> [0]:<br /> WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599<br /> Modules linked in:<br /> CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599<br /> Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52<br /> RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c<br /> RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001<br /> RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680<br /> R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e<br /> FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349<br /> ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> NF_HOOK include/linux/netfilter.h:308 [inline]<br /> ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569<br /> __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624<br /> __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738<br /> netif_receive_skb_internal net/core/dev.c:5824 [inline]<br /> netif_receive_skb+0x271/0x300 net/core/dev.c:5884<br /> tun_rx_batched drivers/net/tun.c:1549 [inline]<br /> tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002<br /> tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0x76f/0x8d0 fs/read_write.c:590<br /> ksys_write+0xbf/0x190 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x41/0x50 fs/read_write.c:652<br /> x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7fc44a68bc1f<br /> Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48<br /> RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f<br /> R<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: prefer nft_chain_validate<br /> <br /> nft_chain_validate already performs loop detection because a cycle will<br /> result in a call stack overflow (ctx-&gt;level &gt;= NFT_JUMP_STACK_SIZE).<br /> <br /> It also follows maps via -&gt;validate callback in nft_lookup, so there<br /> appears no reason to iterate the maps again.<br /> <br /> nf_tables_check_loops() and all its helper functions can be removed.<br /> This improves ruleset load time significantly, from 23s down to 12s.<br /> <br /> This also fixes a crash bug. Old loop detection code can result in<br /> unbounded recursion:<br /> <br /> BUG: TASK stack guard page was hit at ....<br /> Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1<br /> [..]<br /> <br /> with a suitable ruleset during validation of register stores.<br /> <br /> I can&amp;#39;t see any actual reason to attempt to check for this from<br /> nft_validate_register_store(), at this point the transaction is still in<br /> progress, so we don&amp;#39;t have a full picture of the rule graph.<br /> <br /> For nf-next it might make sense to either remove it or make this depend<br /> on table-&gt;validate_state in case we could catch an error earlier<br /> (for improved error reporting to userspace).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: reject claimed-as-LCP but actually malformed packets<br /> <br /> Since &amp;#39;ppp_async_encode()&amp;#39; assumes valid LCP packets (with code<br /> from 1 to 7 inclusive), add &amp;#39;ppp_check_packet()&amp;#39; to ensure that<br /> LCP packet has an actual body beyond PPP_LCP header bytes, and<br /> reject claimed-as-LCP but actually malformed data otherwise.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: lantiq_etop: fix double free in detach<br /> <br /> The number of the currently released descriptor is never incremented<br /> which results in the same skb being released multiple times.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/deadline: Fix task_struct reference leak<br /> <br /> During the execution of the following stress test with linux-rt:<br /> <br /> stress-ng --cyclic 30 --timeout 30 --minimize --quiet<br /> <br /> kmemleak frequently reported a memory leak concerning the task_struct:<br /> <br /> unreferenced object 0xffff8881305b8000 (size 16136):<br /> comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s)<br /> object hex dump (first 32 bytes):<br /> 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@..............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> debug hex dump (first 16 bytes):<br /> 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S...............<br /> backtrace:<br /> [] dup_task_struct+0x30/0x540<br /> [] copy_process+0x3d9/0x50e0<br /> [] kernel_clone+0xb0/0x770<br /> [] __do_sys_clone+0xb6/0xf0<br /> [] do_syscall_64+0x5d/0xf0<br /> [] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> The issue occurs in start_dl_timer(), which increments the task_struct<br /> reference count and sets a timer. The timer callback, dl_task_timer,<br /> is supposed to decrement the reference count upon expiration. However,<br /> if enqueue_task_dl() is called before the timer expires and cancels it,<br /> the reference count is not decremented, leading to the leak.<br /> <br /> This patch fixes the reference leak by ensuring the task_struct<br /> reference count is properly decremented when the timer is canceled.

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 /> misc: fastrpc: Fix memory leak in audio daemon attach operation<br /> <br /> Audio PD daemon send the name as part of the init IOCTL call. This<br /> name needs to be copied to kernel for which memory is allocated.<br /> This memory is never freed which might result in memory leak. Free<br /> the memory when it is not needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: davinci_mmc: Prevent transmitted data size from exceeding sgm&amp;#39;s length<br /> <br /> No check is done on the size of the data to be transmiited. This causes<br /> a kernel panic when this size exceeds the sg_miter&amp;#39;s length.<br /> <br /> Limit the number of transmitted bytes to sgm-&gt;length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: core: limit cell sysfs permissions to main attribute ones<br /> <br /> The cell sysfs attribute should not provide more access to the nvmem<br /> data than the main attribute itself.<br /> For example if nvme_config::root_only was set, the cell attribute<br /> would still provide read access to everybody.<br /> <br /> Mask out permissions not available on the main attribute.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/filemap: skip to create PMD-sized page cache if needed<br /> <br /> On ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB. The<br /> PMD-sized page cache can&amp;#39;t be supported by xarray as the following error<br /> messages indicate.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128<br /> Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \<br /> nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \<br /> nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \<br /> ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm \<br /> fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \<br /> sha1_ce virtio_net net_failover virtio_console virtio_blk failover \<br /> dimlib virtio_mmio<br /> CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024<br /> pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : xas_split_alloc+0xf8/0x128<br /> lr : split_huge_page_to_list_to_order+0x1c4/0x720<br /> sp : ffff800087a4f6c0<br /> x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff<br /> x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858<br /> x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000<br /> x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000<br /> x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000<br /> x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020<br /> x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28<br /> x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8<br /> x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40<br /> x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000<br /> Call trace:<br /> xas_split_alloc+0xf8/0x128<br /> split_huge_page_to_list_to_order+0x1c4/0x720<br /> truncate_inode_partial_folio+0xdc/0x160<br /> truncate_inode_pages_range+0x1b4/0x4a8<br /> truncate_pagecache_range+0x84/0xa0<br /> xfs_flush_unmap_range+0x70/0x90 [xfs]<br /> xfs_file_fallocate+0xfc/0x4d8 [xfs]<br /> vfs_fallocate+0x124/0x2e8<br /> ksys_fallocate+0x4c/0xa0<br /> __arm64_sys_fallocate+0x24/0x38<br /> invoke_syscall.constprop.0+0x7c/0xd8<br /> do_el0_svc+0xb4/0xd0<br /> el0_svc+0x44/0x1d8<br /> el0t_64_sync_handler+0x134/0x150<br /> el0t_64_sync+0x17c/0x180<br /> <br /> Fix it by skipping to allocate PMD-sized page cache when its size is<br /> larger than MAX_PAGECACHE_ORDER. For this specific case, we will fall to<br /> regular path where the readahead window is determined by BDI&amp;#39;s sysfs file<br /> (read_ahead_kb).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: vmalloc: check if a hash-index is in cpu_possible_mask<br /> <br /> The problem is that there are systems where cpu_possible_mask has gaps<br /> between set CPUs, for example SPARC. In this scenario addr_to_vb_xa()<br /> hash function can return an index which accesses to not-possible and not<br /> setup CPU area using per_cpu() macro. This results in an oops on SPARC.<br /> <br /> A per-cpu vmap_block_queue is also used as hash table, incorrectly<br /> assuming the cpu_possible_mask has no gaps. Fix it by adjusting an index<br /> to a next possible CPU.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Fix userfaultfd_api to return EINVAL as expected<br /> <br /> Currently if we request a feature that is not set in the Kernel config we<br /> fail silently and return all the available features. However, the man<br /> page indicates we should return an EINVAL.<br /> <br /> We need to fix this issue since we can end up with a Kernel warning should<br /> a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with<br /> the config not set with this feature.<br /> <br /> [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660<br /> [ 200.820738] Modules linked in:<br /> [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8<br /> [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022<br /> [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660