Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Fix access violation during port device removal<br /> <br /> Testing with KASAN and syzkaller revealed a bug in port.c:disable_store():<br /> usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to<br /> is concurrently removed, but the function does not check for this<br /> possibility before dereferencing the returned value.<br /> <br /> It turns out that the first dereference is unnecessary, since hub-&gt;intfdev<br /> is the parent of the port device, so it can be changed easily. Adding a<br /> check for hub == NULL prevents further problems.<br /> <br /> The same bug exists in the disable_show() routine, and it can be fixed the<br /> same way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Atom Integrated System Info v2_2 for DCN35<br /> <br /> New request from KMD/VBIOS in order to support new UMA carveout<br /> model. This fixes a null dereference from accessing<br /> Ctx-&gt;dc_bios-&gt;integrated_info while it was NULL.<br /> <br /> DAL parses through the BIOS and extracts the necessary<br /> integrated_info but was missing a case for the new BIOS<br /> version 2.3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: cdev: fix uninitialised kfifo<br /> <br /> If a line is requested with debounce, and that results in debouncing<br /> in software, and the line is subsequently reconfigured to enable edge<br /> detection then the allocation of the kfifo to contain edge events is<br /> overlooked. This results in events being written to and read from an<br /> uninitialised kfifo. Read events are returned to userspace.<br /> <br /> Initialise the kfifo in the case where the software debounce is<br /> already active.

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 /> 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 /> 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 /> 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 /> mptcp: ensure snd_nxt is properly initialized on connect<br /> <br /> Christoph reported a splat hinting at a corrupted snd_una:<br /> <br /> WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005<br /> Modules linked in:<br /> CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> Workqueue: events mptcp_worker<br /> RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005<br /> Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8<br /> 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe<br /> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9<br /> RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4<br /> RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000<br /> R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000<br /> FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0<br /> Call Trace:<br /> <br /> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]<br /> mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]<br /> __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615<br /> mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767<br /> process_one_work+0x1e0/0x560 kernel/workqueue.c:3254<br /> process_scheduled_works kernel/workqueue.c:3335 [inline]<br /> worker_thread+0x3c7/0x640 kernel/workqueue.c:3416<br /> kthread+0x121/0x170 kernel/kthread.c:388<br /> ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243<br /> <br /> <br /> When fallback to TCP happens early on a client socket, snd_nxt<br /> is not yet initialized and any incoming ack will copy such value<br /> into snd_una. If the mptcp worker (dumbly) tries mptcp-level<br /> re-injection after such ack, that would unconditionally trigger a send<br /> buffer cleanup using &amp;#39;bad&amp;#39; snd_una values.<br /> <br /> We could easily disable re-injection for fallback sockets, but such<br /> dumb behavior already helped catching a few subtle issues and a very<br /> low to zero impact in practice.<br /> <br /> Instead address the issue always initializing snd_nxt (and write_seq,<br /> for consistency) at connect time.