Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix kernel crash when devlink reload during initialization<br /> <br /> The devlink reload process will access the hardware resources,<br /> but the register operation is done before the hardware is initialized.<br /> So, processing the devlink reload during initialization may lead to kernel<br /> crash.<br /> <br /> This patch fixes this by registering the devlink after<br /> hardware initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent NULL dereference in ip6_output()<br /> <br /> According to syzbot, there is a chance that ip6_dst_idev()<br /> returns NULL in ip6_output(). Most places in IPv6 stack<br /> deal with a NULL idev just fine, but not here.<br /> <br /> syzbot reported:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]<br /> CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024<br /> RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237<br /> Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff<br /> RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202<br /> RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000<br /> RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48<br /> RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad<br /> R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0<br /> R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000<br /> FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358<br /> sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248<br /> sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653<br /> sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783<br /> sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]<br /> sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212<br /> sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]<br /> sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169<br /> sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73<br /> __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234<br /> sctp_connect net/sctp/socket.c:4819 [inline]<br /> sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834<br /> __sys_connect_file net/socket.c:2048 [inline]<br /> __sys_connect+0x2df/0x310 net/socket.c:2065<br /> __do_sys_connect net/socket.c:2075 [inline]<br /> __se_sys_connect net/socket.c:2072 [inline]<br /> __x64_sys_connect+0x7a/0x90 net/socket.c:2072<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()<br /> <br /> syzbot is able to trigger the following crash [1],<br /> caused by unsafe ip6_dst_idev() use.<br /> <br /> Indeed ip6_dst_idev() can return NULL, and must always be checked.<br /> <br /> [1]<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024<br /> RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]<br /> RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267<br /> Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c<br /> RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700<br /> RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760<br /> RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd<br /> R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000<br /> R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00<br /> FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317<br /> fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108<br /> ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]<br /> ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649<br /> ip6_route_output include/net/ip6_route.h:93 [inline]<br /> ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120<br /> ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250<br /> sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326<br /> sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455<br /> sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662<br /> sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099<br /> __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197<br /> sctp_connect net/sctp/socket.c:4819 [inline]<br /> sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834<br /> __sys_connect_file net/socket.c:2048 [inline]<br /> __sys_connect+0x2df/0x310 net/socket.c:2065<br /> __do_sys_connect net/socket.c:2075 [inline]<br /> __se_sys_connect net/socket.c:2072 [inline]<br /> __x64_sys_connect+0x7a/0x90 net/socket.c:2072<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: cdev: Fix use after free in lineinfo_changed_notify<br /> <br /> The use-after-free issue occurs as follows: when the GPIO chip device file<br /> is being closed by invoking gpio_chrdev_release(), watched_lines is freed<br /> by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier<br /> chain failed due to waiting write rwsem. Additionally, one of the GPIO<br /> chip&amp;#39;s lines is also in the release process and holds the notifier chain&amp;#39;s<br /> read rwsem. Consequently, a race condition leads to the use-after-free of<br /> watched_lines.<br /> <br /> Here is the typical stack when issue happened:<br /> <br /> [free]<br /> gpio_chrdev_release()<br /> --&gt; bitmap_free(cdev-&gt;watched_lines) blocking_notifier_chain_unregister()<br /> --&gt; down_write(&amp;nh-&gt;rwsem) __down_write_common()<br /> --&gt; rwsem_down_write_slowpath()<br /> --&gt; schedule_preempt_disabled()<br /> --&gt; schedule()<br /> <br /> [use]<br /> st54spi_gpio_dev_release()<br /> --&gt; gpio_free()<br /> --&gt; gpiod_free()<br /> --&gt; gpiod_free_commit()<br /> --&gt; gpiod_line_state_notify()<br /> --&gt; blocking_notifier_call_chain()<br /> --&gt; down_read(&amp;nh-&gt;rwsem); notifier_call_chain()<br /> --&gt; lineinfo_changed_notify()<br /> --&gt; test_bit(xxxx, cdev-&gt;watched_lines)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix potential uninit-value access in __ip6_make_skb()<br /> <br /> As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in<br /> __ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6-&gt;flowi6_flags<br /> instead of testing HDRINCL on the socket to avoid a race condition which<br /> causes uninit-value access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().<br /> <br /> Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique()<br /> with nice analysis.<br /> <br /> Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for<br /> timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket&amp;#39;s<br /> sk_refcnt after putting it into ehash and releasing the bucket lock.<br /> <br /> Thus, there is a small race window where other threads could try to<br /> reuse the port during connect() and call sock_hold() in tcp_twsk_unique()<br /> for the TIME-WAIT socket with zero refcnt.<br /> <br /> If that happens, the refcnt taken by tcp_twsk_unique() is overwritten<br /> and sock_put() will cause underflow, triggering a real use-after-free<br /> somewhere else.<br /> <br /> To avoid the use-after-free, we need to use refcount_inc_not_zero() in<br /> tcp_twsk_unique() and give up on reusing the port if it returns false.<br /> <br /> [0]:<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110<br /> CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1<br /> Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023<br /> RIP: 0010:refcount_warn_saturate+0xe5/0x110<br /> Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8<br /> RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027<br /> RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0<br /> RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0<br /> R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84<br /> R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0<br /> FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? refcount_warn_saturate+0xe5/0x110<br /> ? __warn+0x81/0x130<br /> ? refcount_warn_saturate+0xe5/0x110<br /> ? report_bug+0x171/0x1a0<br /> ? refcount_warn_saturate+0xe5/0x110<br /> ? handle_bug+0x3c/0x80<br /> ? exc_invalid_op+0x17/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? refcount_warn_saturate+0xe5/0x110<br /> tcp_twsk_unique+0x186/0x190<br /> __inet_check_established+0x176/0x2d0<br /> __inet_hash_connect+0x74/0x7d0<br /> ? __pfx___inet_check_established+0x10/0x10<br /> tcp_v4_connect+0x278/0x530<br /> __inet_stream_connect+0x10f/0x3d0<br /> inet_stream_connect+0x3a/0x60<br /> __sys_connect+0xa8/0xd0<br /> __x64_sys_connect+0x18/0x20<br /> do_syscall_64+0x83/0x170<br /> entry_SYSCALL_64_after_hwframe+0x78/0x80<br /> RIP: 0033:0x7f62c11a885d<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 a3 45 0c 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d<br /> RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003<br /> RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0<br /> R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab: make __free(kfree) accept error pointers<br /> <br /> Currently, if an automatically freed allocation is an error pointer that<br /> will lead to a crash. An example of this is in wm831x_gpio_dbg_show().<br /> <br /> 171 char *label __free(kfree) = gpiochip_dup_line_label(chip, i);<br /> 172 if (IS_ERR(label)) {<br /> 173 dev_err(wm831x-&gt;dev, "Failed to duplicate label\n");<br /> 174 continue;<br /> 175 }<br /> <br /> The auto clean up function should check for error pointers as well,<br /> otherwise we&amp;#39;re going to keep hitting issues like this.

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 /> e1000e: change usleep_range to udelay in PHY mdic access<br /> <br /> This is a partial revert of commit 6dbdd4de0362 ("e1000e: Workaround<br /> for sporadic MDI error on Meteor Lake systems"). The referenced commit<br /> used usleep_range inside the PHY access routines, which are sometimes<br /> called from an atomic context. This can lead to a kernel panic in some<br /> scenarios, such as cable disconnection and reconnection on vPro systems.<br /> <br /> Solve this by changing the usleep_range calls back to udelay.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> workqueue: Fix selection of wake_cpu in kick_pool()<br /> <br /> With cpu_possible_mask=0-63 and cpu_online_mask=0-7 the following<br /> kernel oops was observed:<br /> <br /> smp: Bringing up secondary CPUs ...<br /> smp: Brought up 1 node, 8 CPUs<br /> Unable to handle kernel pointer dereference in virtual kernel address space<br /> Failing address: 0000000000000000 TEID: 0000000000000803<br /> [..]<br /> Call Trace:<br /> arch_vcpu_is_preempted+0x12/0x80<br /> select_idle_sibling+0x42/0x560<br /> select_task_rq_fair+0x29a/0x3b0<br /> try_to_wake_up+0x38e/0x6e0<br /> kick_pool+0xa4/0x198<br /> __queue_work.part.0+0x2bc/0x3a8<br /> call_timer_fn+0x36/0x160<br /> __run_timers+0x1e2/0x328<br /> __run_timer_base+0x5a/0x88<br /> run_timer_softirq+0x40/0x78<br /> __do_softirq+0x118/0x388<br /> irq_exit_rcu+0xc0/0xd8<br /> do_ext_irq+0xae/0x168<br /> ext_int_handler+0xbe/0xf0<br /> psw_idle_exit+0x0/0xc<br /> default_idle_call+0x3c/0x110<br /> do_idle+0xd4/0x158<br /> cpu_startup_entry+0x40/0x48<br /> rest_init+0xc6/0xc8<br /> start_kernel+0x3c4/0x5e0<br /> startup_continue+0x3c/0x50<br /> <br /> The crash is caused by calling arch_vcpu_is_preempted() for an offline<br /> CPU. To avoid this, select the cpu with cpumask_any_and_distribute()<br /> to mask __pod_cpumask with cpu_online_mask. In case no cpu is left in<br /> the pool, skip the assignment.<br /> <br /> tj: This doesn&amp;#39;t fully fix the bug as CPUs can still go down between picking<br /> the target CPU and the wake call. Fixing that likely requires adding<br /> cpu_online() test to either the sched or s390 arch code. However, regardless<br /> of how that is fixed, workqueue shouldn&amp;#39;t be picking a CPU which isn&amp;#39;t<br /> online as that would result in unpredictable and worse behavior.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> maple_tree: fix mas_empty_area_rev() null pointer dereference<br /> <br /> Currently the code calls mas_start() followed by mas_data_end() if the<br /> maple state is MA_START, but mas_start() may return with the maple state<br /> node == NULL. This will lead to a null pointer dereference when checking<br /> information in the NULL node, which is done in mas_data_end().<br /> <br /> Avoid setting the offset if there is no node by waiting until after the<br /> maple state is checked for an empty or single entry state.<br /> <br /> A user could trigger the events to cause a kernel oops by unmapping all<br /> vmas to produce an empty maple tree, then mapping a vma that would cause<br /> the scenario described above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: avoid zeroing outside-object freepointer for single free<br /> <br /> Commit 284f17ac13fe ("mm/slub: handle bulk and single object freeing<br /> separately") splits single and bulk object freeing in two functions<br /> slab_free() and slab_free_bulk() which leads slab_free() to call<br /> slab_free_hook() directly instead of slab_free_freelist_hook().<br /> <br /> If `init_on_free` is set, slab_free_hook() zeroes the object.<br /> Afterward, if `slub_debug=F` and `CONFIG_SLAB_FREELIST_HARDENED` are<br /> set, the do_slab_free() slowpath executes freelist consistency<br /> checks and try to decode a zeroed freepointer which leads to a<br /> "Freepointer corrupt" detection in check_object().<br /> <br /> During bulk free, slab_free_freelist_hook() isn&amp;#39;t affected as it always<br /> sets it objects freepointer using set_freepointer() to maintain its<br /> reconstructed freelist after `init_on_free`.<br /> <br /> For single free, object&amp;#39;s freepointer thus needs to be avoided when<br /> stored outside the object if `init_on_free` is set. The freepointer left<br /> as is, check_object() may later detect an invalid pointer value due to<br /> objects overflow.<br /> <br /> To reproduce, set `slub_debug=FU init_on_free=1 log_level=7` on the<br /> command line of a kernel build with `CONFIG_SLAB_FREELIST_HARDENED=y`.<br /> <br /> dmesg sample log:<br /> [ 10.708715] =============================================================================<br /> [ 10.710323] BUG kmalloc-rnd-05-32 (Tainted: G B T ): Freepointer corrupt<br /> [ 10.712695] -----------------------------------------------------------------------------<br /> [ 10.712695]<br /> [ 10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2)<br /> [ 10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c<br /> [ 10.716698]<br /> [ 10.716698] Bytes b4 ffff9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> [ 10.720703] Object ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> [ 10.720703] Object ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> [ 10.724696] Padding ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> [ 10.724696] Padding ffff9d9a8035667c: 00 00 00 00 ....<br /> [ 10.724696] FIX kmalloc-rnd-05-32: Object at 0xffff9d9a80356600 not freed