Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: fix potential memory leak in vfio_intx_enable()<br /> <br /> If vfio_irq_ctx_alloc() failed will lead to &amp;#39;name&amp;#39; memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: stk1160: fix bounds checking in stk1160_copy_video()<br /> <br /> The subtract in this condition is reversed. The -&gt;length is the length<br /> of the buffer. The -&gt;bytesused is how many bytes we have copied thus<br /> far. When the condition is reversed that means the result of the<br /> subtraction is always negative but since it&amp;#39;s unsigned then the result<br /> is a very high positive value. That means the overflow check is never<br /> true.<br /> <br /> Additionally, the -&gt;bytesused doesn&amp;#39;t actually work for this purpose<br /> because we&amp;#39;re not writing to "buf-&gt;mem + buf-&gt;bytesused". Instead, the<br /> math to calculate the destination where we are writing is a bit<br /> involved. You calculate the number of full lines already written,<br /> multiply by two, skip a line if necessary so that we start on an odd<br /> numbered line, and add the offset into the line.<br /> <br /> To fix this buffer overflow, just take the actual destination where we<br /> are writing, if the offset is already out of bounds print an error and<br /> return. Otherwise, write up to buf-&gt;length bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> stm class: Fix a double free in stm_register_device()<br /> <br /> The put_device(&amp;stm-&gt;dev) call will trigger stm_device_release() which<br /> frees "stm" so the vfree(stm) on the next line is a double free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: tproxy: bail out if IP has been disabled on the device<br /> <br /> syzbot reports:<br /> general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> [..]<br /> RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62<br /> Call Trace:<br /> nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]<br /> nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168<br /> <br /> __in_dev_get_rcu() can return NULL, so check for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules<br /> <br /> rx_create no longer allocates a modify_hdr instance that needs to be<br /> cleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer<br /> dereference. A leak in the rules also previously occurred since there are<br /> now two rules populated related to status.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 109907067 P4D 109907067 PUD 116890067 PMD 0<br /> Oops: 0000 [#1] SMP<br /> CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014<br /> RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70<br /> <br /> Call Trace:<br /> <br /> ? show_regs+0x60/0x70<br /> ? __die+0x24/0x70<br /> ? page_fault_oops+0x15f/0x430<br /> ? free_to_partial_list.constprop.0+0x79/0x150<br /> ? do_user_addr_fault+0x2c9/0x5c0<br /> ? exc_page_fault+0x63/0x110<br /> ? asm_exc_page_fault+0x27/0x30<br /> ? mlx5_modify_header_dealloc+0xd/0x70<br /> rx_create+0x374/0x590<br /> rx_add_rule+0x3ad/0x500<br /> ? rx_add_rule+0x3ad/0x500<br /> ? mlx5_cmd_exec+0x2c/0x40<br /> ? mlx5_create_ipsec_obj+0xd6/0x200<br /> mlx5e_accel_ipsec_fs_add_rule+0x31/0xf0<br /> mlx5e_xfrm_add_state+0x426/0xc00<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: relax socket state check at accept time.<br /> <br /> Christoph reported the following splat:<br /> <br /> WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0<br /> Modules linked in:<br /> CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759<br /> Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80<br /> RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293<br /> RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64<br /> R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000<br /> R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800<br /> FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786<br /> do_accept+0x435/0x620 net/socket.c:1929<br /> __sys_accept4_file net/socket.c:1969 [inline]<br /> __sys_accept4+0x9b/0x110 net/socket.c:1999<br /> __do_sys_accept net/socket.c:2016 [inline]<br /> __se_sys_accept net/socket.c:2013 [inline]<br /> __x64_sys_accept+0x7d/0x90 net/socket.c:2013<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x4315f9<br /> Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 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 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00<br /> RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b<br /> RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004<br /> RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300<br /> R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055<br /> <br /> <br /> The reproducer invokes shutdown() before entering the listener status.<br /> After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for<br /> TCP_SYN_RECV sockets"), the above causes the child to reach the accept<br /> syscall in FIN_WAIT1 status.<br /> <br /> Eric noted we can relax the existing assertion in __inet_accept()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: fix missing memory barrier in tls_init<br /> <br /> In tls_init(), a write memory barrier is missing, and store-store<br /> reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.<br /> <br /> CPU0 CPU1<br /> ----- -----<br /> // In tls_init()<br /> // In tls_ctx_create()<br /> ctx = kzalloc()<br /> ctx-&gt;sk_proto = READ_ONCE(sk-&gt;sk_prot) -(1)<br /> <br /> // In update_sk_prot()<br /> WRITE_ONCE(sk-&gt;sk_prot, tls_prots) -(2)<br /> <br /> // In sock_common_setsockopt()<br /> READ_ONCE(sk-&gt;sk_prot)-&gt;setsockopt()<br /> <br /> // In tls_{setsockopt,getsockopt}()<br /> ctx-&gt;sk_proto-&gt;setsockopt() -(3)<br /> <br /> In the above scenario, when (1) and (2) are reordered, (3) can observe<br /> the NULL value of ctx-&gt;sk_proto, causing NULL dereference.<br /> <br /> To fix it, we rely on rcu_assign_pointer() which implies the release<br /> barrier semantic. By moving rcu_assign_pointer() after ctx-&gt;sk_proto is<br /> initialized, we can ensure that ctx-&gt;sk_proto are visible when<br /> changing sk-&gt;sk_prot.

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 /> ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup<br /> <br /> Use the control private_free callback to free the associated data<br /> block. This ensures that the memory won&amp;#39;t leak, whatever way the<br /> control gets destroyed.<br /> <br /> The original implementation didn&amp;#39;t actually remove the ALSA<br /> controls in hda_cs_dsp_control_remove(). It only freed the internal<br /> tracking structure. This meant it was possible to remove/unload the<br /> amp driver while leaving its ALSA controls still present in the<br /> soundcard. Obviously attempting to access them could cause segfaults<br /> or at least dereferencing stale pointers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails<br /> <br /> Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer<br /> dereference on:<br /> <br /> msm_gpu_cleanup() : platform_set_drvdata(gpu-&gt;pdev, NULL);<br /> <br /> as gpu-&gt;pdev is only assigned in:<br /> <br /> a6xx_gpu_init()<br /> |_ adreno_gpu_init<br /> |_ msm_gpu_init()<br /> <br /> Instead of relying on handwavy null checks down the cleanup chain,<br /> explicitly de-allocate the LLC data and free a6xx_gpu instead.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/588919/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> null_blk: fix null-ptr-dereference while configuring &amp;#39;power&amp;#39; and &amp;#39;submit_queues&amp;#39;<br /> <br /> Writing &amp;#39;power&amp;#39; and &amp;#39;submit_queues&amp;#39; concurrently will trigger kernel<br /> panic:<br /> <br /> Test script:<br /> <br /> modprobe null_blk nr_devices=0<br /> mkdir -p /sys/kernel/config/nullb/nullb0<br /> while true; do echo 1 &gt; submit_queues; echo 4 &gt; submit_queues; done &amp;<br /> while true; do echo 1 &gt; power; echo 0 &gt; power; done<br /> <br /> Test result:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000148<br /> Oops: 0000 [#1] PREEMPT SMP<br /> RIP: 0010:__lock_acquire+0x41d/0x28f0<br /> Call Trace:<br /> <br /> lock_acquire+0x121/0x450<br /> down_write+0x5f/0x1d0<br /> simple_recursive_removal+0x12f/0x5c0<br /> blk_mq_debugfs_unregister_hctxs+0x7c/0x100<br /> blk_mq_update_nr_hw_queues+0x4a3/0x720<br /> nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]<br /> nullb_device_submit_queues_store+0x79/0xf0 [null_blk]<br /> configfs_write_iter+0x119/0x1e0<br /> vfs_write+0x326/0x730<br /> ksys_write+0x74/0x150<br /> <br /> This is because del_gendisk() can concurrent with<br /> blk_mq_update_nr_hw_queues():<br /> <br /> nullb_device_power_store nullb_apply_submit_queues<br /> null_del_dev<br /> del_gendisk<br /> nullb_update_nr_hw_queues<br /> if (!dev-&gt;nullb)<br /> // still set while gendisk is deleted<br /> return 0<br /> blk_mq_update_nr_hw_queues<br /> dev-&gt;nullb = NULL<br /> <br /> Fix this problem by resuing the global mutex to protect<br /> nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()<br /> <br /> syzbot reported that nf_reinject() could be called without rcu_read_lock() :<br /> <br /> WARNING: suspicious RCU usage<br /> 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted<br /> <br /> net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 2 locks held by syz-executor.4/13427:<br /> #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]<br /> #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]<br /> #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471<br /> #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]<br /> #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]<br /> #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172<br /> <br /> stack backtrace:<br /> CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114<br /> lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712<br /> nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]<br /> nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397<br /> nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]<br /> instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172<br /> rcu_do_batch kernel/rcu/tree.c:2196 [inline]<br /> rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471<br /> handle_softirqs+0x2d6/0x990 kernel/softirq.c:554<br /> __do_softirq kernel/softirq.c:588 [inline]<br /> invoke_softirq kernel/softirq.c:428 [inline]<br /> __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637<br /> irq_exit_rcu+0x9/0x30 kernel/softirq.c:649<br /> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]<br /> sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043<br /> <br />