ISHACK AI BOT

Debian: CVE-2024-50151: linux, linux-6.1 -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 11/07/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50151 CVE - 2024-50151 DLA-4008-1

Debian: CVE-2024-50153: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device(). Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50153 CVE - 2024-50153 DLA-4008-1

Debian: CVE-2024-50155: linux, linux-6.1 -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 11/07/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: netdevsim: use cond_resched() in nsim_dev_trap_report_work() I am still seeing many syzbot reports hinting that syzbot might fool nsim_dev_trap_report_work() with hundreds of ports [1] Lets use cond_resched(), and system_unbound_wq instead of implicit system_wq. [1] INFO: task syz-executor:20633 blocked for more than 143 seconds. Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executorstate:D stack:25856 pid:20633 tgid:20633 ppid:1flags:0x00004006 ... NMI backtrace for cpu 1 CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events nsim_dev_trap_report_work RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:210 Code: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0 RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246 RAX: 0000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00 RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577 R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000 R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00 FS:0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 spin_unlock_bh include/linux/spinlock.h:396 [inline] nsim_dev_trap_report drivers/net/netdevsim/dev.c:820 [inline] nsim_dev_trap_report_work+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50155 CVE - 2024-50155 DLA-4008-1

VMware Photon OS: CVE-2024-50167 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-50167 CVE - 2024-50167

Debian: CVE-2024-50154: linux, linux-6.1 -- security update Severity 7 CVSS (AV:L/AC:M/Au:S/C:C/I:C/A:C) Published 11/07/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50154 CVE - 2024-50154 DLA-4008-1

Oracle Linux: CVE-2024-50171: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-50171 CVE - 2024-50171 ELSA-2024-12884

Oracle Linux: CVE-2024-50151: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 11/07/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using &apos;seal&apos; mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst-&gt;iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e &quot;print(&apos;a&apos;)for 1..1024&quot;) /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: &lt;TASK&gt; dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-50151 CVE - 2024-50151 ELSA-2024-12884

Oracle Linux: CVE-2024-50168: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:C) Published 11/07/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb-&gt;len being too long, add dev_kfree_skb() to fix it. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-50168 CVE - 2024-50168 ELSA-2024-12884

Oracle Linux: CVE-2024-50143: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:H/Au:S/C:C/I:C/A:C) Published 11/07/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-50143 CVE - 2024-50143 ELSA-2024-12884

Debian: CVE-2024-50145: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx() build_skb() returns NULL in case of a memory allocation failure so handle it inside __octep_oq_process_rx() to avoid NULL pointer dereference. __octep_oq_process_rx() is called during NAPI polling by the driver. If skb allocation fails, keep on pulling packets out of the Rx DMA queue: we shouldn't break the polling immediately and thus falsely indicate to the octep_napi_poll() that the Rx pressure is going down. As there is no associated skb in this case, don't process the packets and don't push them up the network stack - they are skipped. Helper function is implemented to unmmap/flush all the fragment buffers used by the dropped packet. 'alloc_failures' counter is incremented to mark the skb allocation error in driver statistics. Found by Linux Verification Center (linuxtesting.org) with SVACE. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50145 CVE - 2024-50145 DLA-4008-1

Debian: CVE-2024-50164: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 11/07/2024 Created 02/11/2025 Added 02/10/2025 Modified 02/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overloading of MEM_UNINIT's meaning Lonial reported an issue in the BPF verifier where check_mem_size_reg() has the following code: if (!tnum_is_const(reg->var_off)) /* For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. */ meta = NULL; This means that writes are not checked when the register containing the size of the passed buffer has not a fixed size. Through this bug, a BPF program can write to a map which is marked as read-only, for example, .rodata global maps. The problem is that MEM_UNINIT's initial meaning that "the passed buffer to the BPF helper does not need to be initialized" which was added back in commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type") got overloaded over time with "the passed buffer is being written to". The problem however is that checks such as the above which were added later via 06c1c049721a ("bpf: allow helpers access to variable memory") set meta to NULL in order force the user to always initialize the passed buffer to the helper. Due to the current double meaning of MEM_UNINIT, this bypasses verifier write checks to the memory (not boundary checks though) and only assumes the latter memory is read instead. Fix this by reverting MEM_UNINIT back to its original meaning, and having MEM_WRITE as an annotation to BPF helpers in order to then trigger the BPF verifier checks for writing to memory. Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO} we can access fn->arg_type[arg - 1] since it must contain a preceding ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed altogether since we do check both BPF_READ and BPF_WRITE. Same for the equivalent check_kfunc_mem_size_reg(). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-50164 CVE - 2024-50164 DSA-5860-1

Debian: CVE-2024-50167: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50167 CVE - 2024-50167 DLA-4008-1

Debian: CVE-2024-50160: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50160 CVE - 2024-50160 DLA-4008-1

Debian: CVE-2024-50141: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ] Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50141 CVE - 2024-50141 DLA-4008-1

Oracle Linux: CVE-2024-10963: ELSA-2024-10244:pam:1.5.1 security update (IMPORTANT) (Multiple Advisories) Severity 7 CVSS (AV:N/AC:H/Au:N/C:C/I:C/A:N) Published 11/07/2024 Created 11/28/2024 Added 11/26/2024 Modified 01/07/2025 Description A vulnerability was found in pam_access due to the improper handling of tokens in access.conf, interpreted as hostnames. This flaw allows attackers to bypass access restrictions by spoofing hostnames, undermining configurations designed to limit access to specific TTYs or services. The flaw poses a risk in environments relying on these configurations for local access control. Solution(s) oracle-linux-upgrade-pam oracle-linux-upgrade-pam-devel oracle-linux-upgrade-pam-docs References https://attackerkb.com/topics/cve-2024-10963 CVE - 2024-10963 ELSA-2024-10244 ELSA-2024-10379

Amazon Linux 2023: CVE-2024-50146: Important priority package update for kernel Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 11/07/2024 Created 02/05/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Don&apos;t call cleanup on profile rollback failure When profile rollback fails in mlx5e_netdev_change_profile, the netdev profile var is left set to NULL. Avoid a crash when unloading the driver by not calling profile-&gt;cleanup in such a case. This was encountered while testing, with the original trigger that the wq rescuer thread creation got interrupted (presumably due to Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by mlx5e_priv_init, the profile rollback also fails for the same reason (signal still active) so the profile is left as NULL, leading to a crash later in _mlx5e_remove. [732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2) [734.525513] workqueue: Failed to create a rescuer kthread for wq &quot;mlx5e&quot;: -EINTR [734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12 [734.560153] workqueue: Failed to create a rescuer kthread for wq &quot;mlx5e&quot;: -EINTR [734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 [745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008 [745.538222] #PF: supervisor read access in kernel mode &lt;snipped&gt; [745.551290] Call Trace: [745.551590]&lt;TASK&gt; [745.551866]? __die+0x20/0x60 [745.552218]? page_fault_oops+0x150/0x400 [745.555307]? exc_page_fault+0x79/0x240 [745.555729]? asm_exc_page_fault+0x22/0x30 [745.556166]? mlx5e_remove+0x6b/0xb0 [mlx5_core] [745.556698]auxiliary_bus_remove+0x18/0x30 [745.557134]device_release_driver_internal+0x1df/0x240 [745.557654]bus_remove_device+0xd7/0x140 [745.558075]device_del+0x15b/0x3c0 [745.558456]mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core] [745.559112]mlx5_unregister_device+0x34/0x50 [mlx5_core] [745.559686]mlx5_uninit_one+0x46/0xf0 [mlx5_core] [745.560203]remove_one+0x4e/0xd0 [mlx5_core] [745.560694]pci_device_remove+0x39/0xa0 [745.561112]device_release_driver_internal+0x1df/0x240 [745.561631]driver_detach+0x47/0x90 [745.562022]bus_remove_driver+0x84/0x100 [745.562444]pci_unregister_driver+0x3b/0x90 [745.562890]mlx5_cleanup+0xc/0x1b [mlx5_core] [745.563415]__x64_sys_delete_module+0x14d/0x2f0 [745.563886]? kmem_cache_free+0x1b0/0x460 [745.564313]? lockdep_hardirqs_on_prepare+0xe2/0x190 [745.564825]do_syscall_64+0x6d/0x140 [745.565223]entry_SYSCALL_64_after_hwframe+0x4b/0x53 [745.565725] RIP: 0033:0x7f1579b1288b Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-124-134-200 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-50146 CVE - 2024-50146 https://alas.aws.amazon.com/AL2023/ALAS-2025-809.html

Amazon Linux 2023: CVE-2024-50150: Important priority package update for kernel Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 02/05/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: &apos;port0.0&apos; (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: &apos;port0.1&apos; (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: &apos;port0&apos; (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: &apos;port1.0&apos; (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: &apos;port1.1&apos; (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: &apos;typec&apos; (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: &apos;port1&apos; (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648]&lt;TASK&gt; [ 46.616820]dump_stack_lvl+0x5b/0x7c [ 46.617112]? typec_altmode_release+0x38/0x129 [ 46.617470]print_report+0x14c/0x49e [ 46.617769]? rcu_read_unlock_sched+0x56/0x69 [ 46.618117]? __virt_addr_valid+0x19a/0x1ab [ 46.618456]? kmem_cache_debug_flags+0xc/0x1d [ 46.618807]? typec_altmode_release+0x38/0x129 [ 46.619161]kasan_report+0x8d/0xb4 [ 46.619447]? typec_altmode_release+0x38/0x129 [ 46.619809]? process_scheduled_works+0x3cb/0x85f [ 46.620185]typec_altmode_release+0x38/0x129 [ 46.620537]? process_scheduled_works+0x3cb/0x85f [ 46.620907]device_release+0xaf/0xf2 [ 46.621206]kobject_delayed_cleanup+0x13b/0x17a [ 46.621584]process_scheduled_works+0x4f6/0x85f [ 46.621955]? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353]? hlock_class+0x31/0x9a [ 46.622647]? lock_acquired+0x361/0x3c3 [ 46.622956]? move_linked_works+0x46/0x7d [ 46.623277]worker_thread+0x1ce/0x291 [ 46.623582]? __kthread_parkme+0xc8/0xdf [ 46.623900]? __pfx_worker_thread+0x10/0x10 [ 46.624236]kthread+0x17e/0x190 [ 46.624501]? kthread+0xfb/0x190 [ 46.624756]? __pfx_kthread+0x10/0x10 [ 46.625015]ret_from_fork+0x20/0x40 [ 46.625268]? __pfx_kthread+0x10/0x10 [ 46.625532]ret_from_fork_asm+0x1a/0x30 [ 46.625805]&lt;/TASK&gt; [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287]kasan_save_stack+0x24/0x44 [ 46.626555]kasan_save_track+0x14/0x2d [ 46.626811]__kasan_kmalloc+0x3f/0x4d [ 46.627049]__kmalloc_noprof+0x1bf/0x1f0 [ 46.627362]typec_register_port+0x23/0x491 [ 46.627698]cros_typec_probe+0x634/0xbb6 [ 46.628026]platform_probe+0x47/0x8c [ 46.628311]really_probe+0x20a/0x47d [ 46.628605]device_driver_attach+0x39/0x72 [ 46.628940]bind_store+0x87/0xd7 [ 46.629213]kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574]vfs_write+0x1d6/0x29b [ 46.629856]ksys_write+0xcd/0x13b [ 46.630128]do_syscall_64+0xd4/0x139 [ 46.630420]entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182]kasan_save_stack+0x24/0x44 [ 46.631493]kasan_save_track+0x14/0x2d [ 46.631799]kasan_save_free_info+0x3f/0x4d [ 46.632144]__kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated--- Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-115-126-197 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-50150 CVE - 2024-50150 https://alas.aws.amazon.com/AL2023/ALAS-2025-794.html

Amazon Linux 2023: CVE-2024-50143: Important priority package update for kernel Severity 6 CVSS (AV:L/AC:H/Au:S/C:C/I:C/A:C) Published 11/07/2024 Created 02/05/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-115-126-197 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-50143 CVE - 2024-50143 https://alas.aws.amazon.com/AL2023/ALAS-2025-794.html

VMware Photon OS: CVE-2024-50154 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 11/07/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-50154 CVE - 2024-50154

VMware Photon OS: CVE-2024-50143 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 11/07/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-50143 CVE - 2024-50143

Debian: CVE-2024-50147: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix command bitmask initialization Command bitmask have a dedicated bit for MANAGE_PAGES command, this bit isn't Initialize during command bitmask Initialization, only during MANAGE_PAGES. In addition, mlx5_cmd_trigger_completions() is trying to trigger completion for MANAGE_PAGES command as well. Hence, in case health error occurred before any MANAGE_PAGES command have been invoke (for example, during mlx5_enable_hca()), mlx5_cmd_trigger_completions() will try to trigger completion for MANAGE_PAGES command, which will result in null-ptr-deref error.[1] Fix it by Initialize command bitmask correctly. While at it, re-write the code for better understanding. [1] BUG: KASAN: null-ptr-deref in mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core] Write of size 4 at addr 0000000000000214 by task kworker/u96:2/12078 CPU: 10 PID: 12078 Comm: kworker/u96:2 Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: <TASK> dump_stack_lvl+0x7e/0xc0 kasan_report+0xb9/0xf0 kasan_check_range+0xec/0x190 mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core] mlx5_cmd_flush+0x94/0x240 [mlx5_core] enter_error_state+0x6c/0xd0 [mlx5_core] mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core] process_one_work+0x787/0x1490 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? pwq_dec_nr_in_flight+0xda0/0xda0 ? assign_work+0x168/0x240 worker_thread+0x586/0xd30 ? rescuer_thread+0xae0/0xae0 kthread+0x2df/0x3b0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x2d/0x70 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 </TASK> Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50147 CVE - 2024-50147 DLA-4008-1

Debian: CVE-2024-50146: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 11/07/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Don't call cleanup on profile rollback failure When profile rollback fails in mlx5e_netdev_change_profile, the netdev profile var is left set to NULL. Avoid a crash when unloading the driver by not calling profile->cleanup in such a case. This was encountered while testing, with the original trigger that the wq rescuer thread creation got interrupted (presumably due to Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by mlx5e_priv_init, the profile rollback also fails for the same reason (signal still active) so the profile is left as NULL, leading to a crash later in _mlx5e_remove. [732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2) [734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12 [734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 [745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008 [745.538222] #PF: supervisor read access in kernel mode <snipped> [745.551290] Call Trace: [745.551590]<TASK> [745.551866]? __die+0x20/0x60 [745.552218]? page_fault_oops+0x150/0x400 [745.555307]? exc_page_fault+0x79/0x240 [745.555729]? asm_exc_page_fault+0x22/0x30 [745.556166]? mlx5e_remove+0x6b/0xb0 [mlx5_core] [745.556698]auxiliary_bus_remove+0x18/0x30 [745.557134]device_release_driver_internal+0x1df/0x240 [745.557654]bus_remove_device+0xd7/0x140 [745.558075]device_del+0x15b/0x3c0 [745.558456]mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core] [745.559112]mlx5_unregister_device+0x34/0x50 [mlx5_core] [745.559686]mlx5_uninit_one+0x46/0xf0 [mlx5_core] [745.560203]remove_one+0x4e/0xd0 [mlx5_core] [745.560694]pci_device_remove+0x39/0xa0 [745.561112]device_release_driver_internal+0x1df/0x240 [745.561631]driver_detach+0x47/0x90 [745.562022]bus_remove_driver+0x84/0x100 [745.562444]pci_unregister_driver+0x3b/0x90 [745.562890]mlx5_cleanup+0xc/0x1b [mlx5_core] [745.563415]__x64_sys_delete_module+0x14d/0x2f0 [745.563886]? kmem_cache_free+0x1b0/0x460 [745.564313]? lockdep_hardirqs_on_prepare+0xe2/0x190 [745.564825]do_syscall_64+0x6d/0x140 [745.565223]entry_SYSCALL_64_after_hwframe+0x4b/0x53 [745.565725] RIP: 0033:0x7f1579b1288b Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-50146 CVE - 2024-50146

Huawei EulerOS: CVE-2024-50143: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 11/07/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-50143 CVE - 2024-50143 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2024-10963: pam security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 11/07/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description A flaw was found in pam_access, where certain rules in its configuration file are mistakenly treated as hostnames. This vulnerability allows attackers to trick the system by pretending to be a trusted hostname, gaining unauthorized access. This issue poses a risk for systems that rely on this feature to control who can access certain services or terminals. Solution(s) huawei-euleros-2_0_sp11-upgrade-pam References https://attackerkb.com/topics/cve-2024-10963 CVE - 2024-10963 EulerOS-SA-2025-1161

Huawei EulerOS: CVE-2024-50150: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 11/07/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648]<TASK> [ 46.616820]dump_stack_lvl+0x5b/0x7c [ 46.617112]? typec_altmode_release+0x38/0x129 [ 46.617470]print_report+0x14c/0x49e [ 46.617769]? rcu_read_unlock_sched+0x56/0x69 [ 46.618117]? __virt_addr_valid+0x19a/0x1ab [ 46.618456]? kmem_cache_debug_flags+0xc/0x1d [ 46.618807]? typec_altmode_release+0x38/0x129 [ 46.619161]kasan_report+0x8d/0xb4 [ 46.619447]? typec_altmode_release+0x38/0x129 [ 46.619809]? process_scheduled_works+0x3cb/0x85f [ 46.620185]typec_altmode_release+0x38/0x129 [ 46.620537]? process_scheduled_works+0x3cb/0x85f [ 46.620907]device_release+0xaf/0xf2 [ 46.621206]kobject_delayed_cleanup+0x13b/0x17a [ 46.621584]process_scheduled_works+0x4f6/0x85f [ 46.621955]? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353]? hlock_class+0x31/0x9a [ 46.622647]? lock_acquired+0x361/0x3c3 [ 46.622956]? move_linked_works+0x46/0x7d [ 46.623277]worker_thread+0x1ce/0x291 [ 46.623582]? __kthread_parkme+0xc8/0xdf [ 46.623900]? __pfx_worker_thread+0x10/0x10 [ 46.624236]kthread+0x17e/0x190 [ 46.624501]? kthread+0xfb/0x190 [ 46.624756]? __pfx_kthread+0x10/0x10 [ 46.625015]ret_from_fork+0x20/0x40 [ 46.625268]? __pfx_kthread+0x10/0x10 [ 46.625532]ret_from_fork_asm+0x1a/0x30 [ 46.625805]</TASK> [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287]kasan_save_stack+0x24/0x44 [ 46.626555]kasan_save_track+0x14/0x2d [ 46.626811]__kasan_kmalloc+0x3f/0x4d [ 46.627049]__kmalloc_noprof+0x1bf/0x1f0 [ 46.627362]typec_register_port+0x23/0x491 [ 46.627698]cros_typec_probe+0x634/0xbb6 [ 46.628026]platform_probe+0x47/0x8c [ 46.628311]really_probe+0x20a/0x47d [ 46.628605]device_driver_attach+0x39/0x72 [ 46.628940]bind_store+0x87/0xd7 [ 46.629213]kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574]vfs_write+0x1d6/0x29b [ 46.629856]ksys_write+0xcd/0x13b [ 46.630128]do_syscall_64+0xd4/0x139 [ 46.630420]entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182]kasan_save_stack+0x24/0x44 [ 46.631493]kasan_save_track+0x14/0x2d [ 46.631799]kasan_save_free_info+0x3f/0x4d [ 46.632144]__kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated--- Solution(s) huawei-euleros-2_0_sp11-upgrade-bpftool huawei-euleros-2_0_sp11-upgrade-kernel huawei-euleros-2_0_sp11-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp11-upgrade-kernel-tools huawei-euleros-2_0_sp11-upgrade-kernel-tools-libs huawei-euleros-2_0_sp11-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-50150 CVE - 2024-50150 EulerOS-SA-2025-1159