Vulnerabilities

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 />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix shift-out-of-bounds in dctcp_update_alpha().<br /> <br /> In dctcp_update_alpha(), we use a module parameter dctcp_shift_g<br /> as follows:<br /> <br /> alpha -= min_not_zero(alpha, alpha &gt;&gt; dctcp_shift_g);<br /> ...<br /> delivered_ce /sys/module/tcp_dctcp/parameters/dctcp_shift_g<br /> -bash: echo: write error: Invalid argument<br /> <br /> [0]:<br /> UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12<br /> shift exponent 100 is too large for 32-bit type &amp;#39;u32&amp;#39; (aka &amp;#39;unsigned int&amp;#39;)<br /> CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114<br /> ubsan_epilogue lib/ubsan.c:231 [inline]<br /> __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468<br /> dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143<br /> tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]<br /> tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948<br /> tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711<br /> tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937<br /> sk_backlog_rcv include/net/sock.h:1106 [inline]<br /> __release_sock+0x20f/0x350 net/core/sock.c:2983<br /> release_sock+0x61/0x1f0 net/core/sock.c:3549<br /> mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907<br /> mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976<br /> __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072<br /> mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127<br /> inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437<br /> __sock_release net/socket.c:659 [inline]<br /> sock_close+0xc0/0x240 net/socket.c:1421<br /> __fput+0x41b/0x890 fs/file_table.c:422<br /> task_work_run+0x23b/0x300 kernel/task_work.c:180<br /> exit_task_work include/linux/task_work.h:38 [inline]<br /> do_exit+0x9c8/0x2540 kernel/exit.c:878<br /> do_group_exit+0x201/0x2b0 kernel/exit.c:1027<br /> __do_sys_exit_group kernel/exit.c:1038 [inline]<br /> __se_sys_exit_group kernel/exit.c:1036 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> RIP: 0033:0x7f6c2b5005b6<br /> Code: Unable to access opcode bytes at 0x7f6c2b50058c.<br /> RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6<br /> RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001<br /> RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0<br /> R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0<br /> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nci: Fix uninit-value in nci_rx_work<br /> <br /> syzbot reported the following uninit-value access issue [1]<br /> <br /> nci_rx_work() parses received packet from ndev-&gt;rx_q. It should be<br /> validated header size, payload size and total packet size before<br /> processing the packet. If an invalid packet is detected, it should be<br /> silently discarded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: cyapa - add missing input core locking to suspend/resume functions<br /> <br /> Grab input-&gt;mutex during suspend/resume functions like it is done in<br /> other input drivers. This fixes the following warning during system<br /> suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c<br /> Modules linked in: ...<br /> CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109<br /> Hardware name: Samsung Exynos (Flattened Device Tree)<br /> Workqueue: events_unbound async_run_entry_fn<br /> unwind_backtrace from show_stack+0x10/0x14<br /> show_stack from dump_stack_lvl+0x58/0x70<br /> dump_stack_lvl from __warn+0x1a8/0x1cc<br /> __warn from warn_slowpath_fmt+0x18c/0x1b4<br /> warn_slowpath_fmt from input_device_enabled+0x68/0x6c<br /> input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc<br /> cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c<br /> cyapa_reinitialize from cyapa_resume+0x48/0x98<br /> cyapa_resume from dpm_run_callback+0x90/0x298<br /> dpm_run_callback from device_resume+0xb4/0x258<br /> device_resume from async_resume+0x20/0x64<br /> async_resume from async_run_entry_fn+0x40/0x15c<br /> async_run_entry_fn from process_scheduled_works+0xbc/0x6a8<br /> process_scheduled_works from worker_thread+0x188/0x454<br /> worker_thread from kthread+0x108/0x140<br /> kthread from ret_from_fork+0x14/0x28<br /> Exception stack(0xf1625fb0 to 0xf1625ff8)<br /> ...<br /> ---[ end trace 0000000000000000 ]---<br /> ...<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c<br /> Modules linked in: ...<br /> CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109<br /> Hardware name: Samsung Exynos (Flattened Device Tree)<br /> Workqueue: events_unbound async_run_entry_fn<br /> unwind_backtrace from show_stack+0x10/0x14<br /> show_stack from dump_stack_lvl+0x58/0x70<br /> dump_stack_lvl from __warn+0x1a8/0x1cc<br /> __warn from warn_slowpath_fmt+0x18c/0x1b4<br /> warn_slowpath_fmt from input_device_enabled+0x68/0x6c<br /> input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc<br /> cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c<br /> cyapa_reinitialize from cyapa_resume+0x48/0x98<br /> cyapa_resume from dpm_run_callback+0x90/0x298<br /> dpm_run_callback from device_resume+0xb4/0x258<br /> device_resume from async_resume+0x20/0x64<br /> async_resume from async_run_entry_fn+0x40/0x15c<br /> async_run_entry_fn from process_scheduled_works+0xbc/0x6a8<br /> process_scheduled_works from worker_thread+0x188/0x454<br /> worker_thread from kthread+0x108/0x140<br /> kthread from ret_from_fork+0x14/0x28<br /> Exception stack(0xf1625fb0 to 0xf1625ff8)<br /> ...<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: libstub: only free priv.runtime_map when allocated<br /> <br /> priv.runtime_map is only allocated when efi_novamap is not set.<br /> Otherwise, it is an uninitialized value. In the error path, it is freed<br /> unconditionally. Avoid passing an uninitialized value to free_pool.<br /> Free priv.runtime_map only when it was allocated.<br /> <br /> This bug was discovered and resolved using Coverity Static Analysis<br /> Security Testing (SAST) by Synopsys, Inc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: taprio: extend minimum interval restriction to entire cycle too<br /> <br /> It is possible for syzbot to side-step the restriction imposed by the<br /> blamed commit in the Fixes: tag, because the taprio UAPI permits a<br /> cycle-time different from (and potentially shorter than) the sum of<br /> entry intervals.<br /> <br /> We need one more restriction, which is that the cycle time itself must<br /> be larger than N * ETH_ZLEN bit times, where N is the number of schedule<br /> entries. This restriction needs to apply regardless of whether the cycle<br /> time came from the user or was the implicit, auto-calculated value, so<br /> we move the existing "cycle == 0" check outside the "if "(!new-&gt;cycle_time)"<br /> branch. This way covers both conditions and scenarios.<br /> <br /> Add a selftest which illustrates the issue triggered by syzbot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline<br /> <br /> The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of<br /> interrupt affinity reconfiguration via procfs. Instead, the change is<br /> deferred until the next instance of the interrupt being triggered on the<br /> original CPU.<br /> <br /> When the interrupt next triggers on the original CPU, the new affinity is<br /> enforced within __irq_move_irq(). A vector is allocated from the new CPU,<br /> but the old vector on the original CPU remains and is not immediately<br /> reclaimed. Instead, apicd-&gt;move_in_progress is flagged, and the reclaiming<br /> process is delayed until the next trigger of the interrupt on the new CPU.<br /> <br /> Upon the subsequent triggering of the interrupt on the new CPU,<br /> irq_complete_move() adds a task to the old CPU&amp;#39;s vector_cleanup list if it<br /> remains online. Subsequently, the timer on the old CPU iterates over its<br /> vector_cleanup list, reclaiming old vectors.<br /> <br /> However, a rare scenario arises if the old CPU is outgoing before the<br /> interrupt triggers again on the new CPU.<br /> <br /> In that case irq_force_complete_move() is not invoked on the outgoing CPU<br /> to reclaim the old apicd-&gt;prev_vector because the interrupt isn&amp;#39;t currently<br /> affine to the outgoing CPU, and irq_needs_fixup() returns false. Even<br /> though __vector_schedule_cleanup() is later called on the new CPU, it<br /> doesn&amp;#39;t reclaim apicd-&gt;prev_vector; instead, it simply resets both<br /> apicd-&gt;move_in_progress and apicd-&gt;prev_vector to 0.<br /> <br /> As a result, the vector remains unreclaimed in vector_matrix, leading to a<br /> CPU vector leak.<br /> <br /> To address this issue, move the invocation of irq_force_complete_move()<br /> before the irq_needs_fixup() call to reclaim apicd-&gt;prev_vector, if the<br /> interrupt is currently or used to be affine to the outgoing CPU.<br /> <br /> Additionally, reclaim the vector in __vector_schedule_cleanup() as well,<br /> following a warning message, although theoretically it should never see<br /> apicd-&gt;move_in_progress with apicd-&gt;prev_cpu pointing to an offline CPU.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvlan: Dont Use skb-&gt;sk in ipvlan_process_v{4,6}_outbound<br /> <br /> Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will<br /> hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.<br /> <br /> WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70<br /> Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper<br /> CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:sk_mc_loop+0x2d/0x70<br /> Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c<br /> RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212<br /> RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001<br /> RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000<br /> RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00<br /> R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000<br /> R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000<br /> FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __warn (kernel/panic.c:693)<br /> ? sk_mc_loop (net/core/sock.c:760)<br /> ? report_bug (lib/bug.c:201 lib/bug.c:219)<br /> ? handle_bug (arch/x86/kernel/traps.c:239)<br /> ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))<br /> ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)<br /> ? sk_mc_loop (net/core/sock.c:760)<br /> ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))<br /> ? nf_hook_slow (net/netfilter/core.c:626)<br /> ip6_finish_output (net/ipv6/ip6_output.c:222)<br /> ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)<br /> ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan<br /> ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan<br /> dev_hard_start_xmit (net/core/dev.c:3594)<br /> sch_direct_xmit (net/sched/sch_generic.c:343)<br /> __qdisc_run (net/sched/sch_generic.c:416)<br /> net_tx_action (net/core/dev.c:5286)<br /> handle_softirqs (kernel/softirq.c:555)<br /> __irq_exit_rcu (kernel/softirq.c:589)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)<br /> <br /> The warning triggers as this:<br /> packet_sendmsg<br /> packet_snd //skb-&gt;sk is packet sk<br /> __dev_queue_xmit<br /> __dev_xmit_skb //q-&gt;enqueue is not NULL<br /> __qdisc_run<br /> sch_direct_xmit<br /> dev_hard_start_xmit<br /> ipvlan_start_xmit<br /> ipvlan_xmit_mode_l3 //l3 mode<br /> ipvlan_process_outbound //vepa flag<br /> ipvlan_process_v6_outbound<br /> ip6_local_out<br /> __ip6_finish_output<br /> ip6_finish_output2 //multicast packet<br /> sk_mc_loop //sk-&gt;sk_family is AF_PACKET<br /> <br /> Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.