Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas()<br /> <br /> Smatch warns:<br /> <br /> arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential<br /> spectre issue &amp;#39;args.args&amp;#39; [r] (local cap)<br /> <br /> The &amp;#39;nargs&amp;#39; and &amp;#39;nret&amp;#39; locals come directly from a user-supplied<br /> buffer and are used as indexes into a small stack-based array and as<br /> inputs to copy_to_user() after they are subject to bounds checks.<br /> <br /> Use array_index_nospec() after the bounds checks to clamp these values<br /> for speculative execution.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: bcm: Remove proc entry when dev is unregistered.<br /> <br /> syzkaller reported a warning in bcm_connect() below. [0]<br /> <br /> The repro calls connect() to vxcan1, removes vxcan1, and calls<br /> connect() with ifindex == 0.<br /> <br /> Calling connect() for a BCM socket allocates a proc entry.<br /> Then, bcm_sk(sk)-&gt;bound is set to 1 to prevent further connect().<br /> <br /> However, removing the bound device resets bcm_sk(sk)-&gt;bound to 0<br /> in bcm_notify().<br /> <br /> The 2nd connect() tries to allocate a proc entry with the same<br /> name and sets NULL to bcm_sk(sk)-&gt;bcm_proc_read, leaking the<br /> original proc entry.<br /> <br /> Since the proc entry is available only for connect()ed sockets,<br /> let&amp;#39;s clean up the entry when the bound netdev is unregistered.<br /> <br /> [0]:<br /> proc_dir_entry &amp;#39;can-bcm/2456&amp;#39; already registered<br /> WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375<br /> Modules linked in:<br /> CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375<br /> Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48<br /> RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246<br /> RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002<br /> RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0<br /> R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec<br /> FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220<br /> bcm_connect+0x472/0x840 net/can/bcm.c:1673<br /> __sys_connect_file net/socket.c:2049 [inline]<br /> __sys_connect+0x5d2/0x690 net/socket.c:2066<br /> __do_sys_connect net/socket.c:2076 [inline]<br /> __se_sys_connect net/socket.c:2073 [inline]<br /> __x64_sys_connect+0x8f/0x100 net/socket.c:2073<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7fbd708b0e5d<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d<br /> RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040<br /> R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098<br /> R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000<br /> <br /> remove_proc_entry: removing non-empty directory &amp;#39;net/can-bcm&amp;#39;, leaking at least &amp;#39;2456&amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check denominator pbn_div before used<br /> <br /> [WHAT &amp; HOW]<br /> A denominator cannot be 0, and is checked before used.<br /> <br /> This fixes 1 DIVIDE_BY_ZERO issue reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Avoid excessive partition lengths<br /> <br /> Avoid mounting filesystems where the partition would overflow the<br /> 32-bits used for block number. Also refuse to mount filesystems where<br /> the partition length is so large we cannot safely index bits in a<br /> block bitmap.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: protect references to superblock parameters exposed in sysfs<br /> <br /> The superblock buffers of nilfs2 can not only be overwritten at runtime<br /> for modifications/repairs, but they are also regularly swapped, replaced<br /> during resizing, and even abandoned when degrading to one side due to<br /> backing device issues. So, accessing them requires mutual exclusion using<br /> the reader/writer semaphore "nilfs-&gt;ns_sem".<br /> <br /> Some sysfs attribute show methods read this superblock buffer without the<br /> necessary mutual exclusion, which can cause problems with pointer<br /> dereferencing and memory access, so fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix missing cleanup on rollforward recovery error<br /> <br /> In an error injection test of a routine for mount-time recovery, KASAN<br /> found a use-after-free bug.<br /> <br /> It turned out that if data recovery was performed using partial logs<br /> created by dsync writes, but an error occurred before starting the log<br /> writer to create a recovered checkpoint, the inodes whose data had been<br /> recovered were left in the ns_dirty_files list of the nilfs object and<br /> were not freed.<br /> <br /> Fix this issue by cleaning up inodes that have read the recovery data if<br /> the recovery routine fails midway before the log writer starts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ila: call nf_unregister_net_hooks() sooner<br /> <br /> syzbot found an use-after-free Read in ila_nf_input [1]<br /> <br /> Issue here is that ila_xlat_exit_net() frees the rhashtable,<br /> then call nf_unregister_net_hooks().<br /> <br /> It should be done in the reverse way, with a synchronize_rcu().<br /> <br /> This is a good match for a pre_exit() method.<br /> <br /> [1]<br /> BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]<br /> BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]<br /> BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]<br /> BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672<br /> Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16<br /> <br /> CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> rht_key_hashfn include/linux/rhashtable.h:159 [inline]<br /> __rhashtable_lookup include/linux/rhashtable.h:604 [inline]<br /> rhashtable_lookup include/linux/rhashtable.h:646 [inline]<br /> rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672<br /> ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]<br /> ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]<br /> ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626<br /> nf_hook include/linux/netfilter.h:269 [inline]<br /> NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312<br /> __netif_receive_skb_one_core net/core/dev.c:5661 [inline]<br /> __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775<br /> process_backlog+0x662/0x15b0 net/core/dev.c:6108<br /> __napi_poll+0xcb/0x490 net/core/dev.c:6772<br /> napi_poll net/core/dev.c:6841 [inline]<br /> net_rx_action+0x89b/0x1240 net/core/dev.c:6963<br /> handle_softirqs+0x2c4/0x970 kernel/softirq.c:554<br /> run_ksoftirqd+0xca/0x130 kernel/softirq.c:928<br /> smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620<br /> flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)<br /> page_type: 0xbfffffff(buddy)<br /> raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000<br /> raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as freed<br /> page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187<br /> set_page_owner include/linux/page_owner.h:32 [inline]<br /> post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493<br /> prep_new_page mm/page_alloc.c:1501 [inline]<br /> get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439<br /> __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695<br /> __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]<br /> alloc_pages_node_noprof include/linux/gfp.h:296 [inline]<br /> ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103<br /> __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130<br /> __do_kmalloc_node mm/slub.c:4146 [inline]<br /> __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164<br /> __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650<br /> bucket_table_alloc lib/rhashtable.c:186 [inline]<br /> rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071<br /> ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613<br /> ops_ini<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_bpf: fix return value of tcp_bpf_sendmsg()<br /> <br /> When we cork messages in psock-&gt;cork, the last message triggers the<br /> flushing will result in sending a sk_msg larger than the current<br /> message size. In this case, in tcp_bpf_send_verdict(), &amp;#39;copied&amp;#39; becomes<br /> negative at least in the following case:<br /> <br /> 468 case __SK_DROP:<br /> 469 default:<br /> 470 sk_msg_free_partial(sk, msg, tosend);<br /> 471 sk_msg_apply_bytes(psock, tosend);<br /> 472 *copied -= (tosend + delta); //

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix error handling in mana_create_txq/rxq&amp;#39;s NAPI cleanup<br /> <br /> Currently napi_disable() gets called during rxq and txq cleanup,<br /> even before napi is enabled and hrtimer is initialized. It causes<br /> kernel panic.<br /> <br /> ? page_fault_oops+0x136/0x2b0<br /> ? page_counter_cancel+0x2e/0x80<br /> ? do_user_addr_fault+0x2f2/0x640<br /> ? refill_obj_stock+0xc4/0x110<br /> ? exc_page_fault+0x71/0x160<br /> ? asm_exc_page_fault+0x27/0x30<br /> ? __mmdrop+0x10/0x180<br /> ? __mmdrop+0xec/0x180<br /> ? hrtimer_active+0xd/0x50<br /> hrtimer_try_to_cancel+0x2c/0xf0<br /> hrtimer_cancel+0x15/0x30<br /> napi_disable+0x65/0x90<br /> mana_destroy_rxq+0x4c/0x2f0<br /> mana_create_rxq.isra.0+0x56c/0x6d0<br /> ? mana_uncfg_vport+0x50/0x50<br /> mana_alloc_queues+0x21b/0x320<br /> ? skb_dequeue+0x5f/0x80

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Remove tst_run from lwt_seg6local_prog_ops.<br /> <br /> The syzbot reported that the lwt_seg6 related BPF ops can be invoked<br /> via bpf_test_run() without without entering input_action_end_bpf()<br /> first.<br /> <br /> Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL<br /> probably didn&amp;#39;t work since it was introduced in commit 04d4b274e2a<br /> ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the<br /> per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self<br /> test case but each BPF function expects it.<br /> <br /> Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.

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

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