ISHACK AI BOT 发布的所有帖子
-
Huawei EulerOS: CVE-2024-26907: kernel security update
Huawei EulerOS: CVE-2024-26907: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 04/17/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS:00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated--- 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-26907 CVE - 2024-26907 EulerOS-SA-2024-2352
-
Huawei EulerOS: CVE-2024-26884: kernel security update
Huawei EulerOS: CVE-2024-26884: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 04/17/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix hashtab overflow check on 32-bit arches The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup. 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-26884 CVE - 2024-26884 EulerOS-SA-2024-2240
-
Huawei EulerOS: CVE-2024-26901: kernel security update
Huawei EulerOS: CVE-2024-26901: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/17/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. 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-26901 CVE - 2024-26901 EulerOS-SA-2024-2240
-
Huawei EulerOS: CVE-2024-26885: kernel security update
Huawei EulerOS: CVE-2024-26885: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 04/17/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation. 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-26885 CVE - 2024-26885 EulerOS-SA-2024-2240
-
Huawei EulerOS: CVE-2024-26907: kernel security update
Huawei EulerOS: CVE-2024-26907: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 04/17/2024 Created 07/16/2024 Added 07/16/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS:00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated--- Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-26907 CVE - 2024-26907 EulerOS-SA-2024-1911
-
Google Chrome Vulnerability: CVE-2024-3838 Inappropriate implementation in Autofill
Google Chrome Vulnerability: CVE-2024-3838 Inappropriate implementation in Autofill Severity 5 CVSS (AV:L/AC:M/Au:N/C:N/I:C/A:N) Published 04/17/2024 Created 04/17/2024 Added 04/17/2024 Modified 01/28/2025 Description Inappropriate implementation in Autofill in Google Chrome prior to 124.0.6367.60 allowed an attacker who convinced a user to install a malicious app to perform UI spoofing via a crafted app. (Chromium security severity: Medium) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-3838 CVE - 2024-3838 https://chromereleases.googleblog.com/2024/04/stable-channel-update-for-desktop_16.html
-
Debian: CVE-2024-26907: linux -- security update
Debian: CVE-2024-26907: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 04/17/2024 Created 05/08/2024 Added 05/08/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS:00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-26907 CVE - 2024-26907 DSA-5681-1
-
Rocky Linux: CVE-2024-2961: glibc (Multiple Advisories)
Rocky Linux: CVE-2024-2961: glibc (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/17/2024 Created 05/10/2024 Added 05/13/2024 Modified 02/14/2025 Description The iconv() function in the GNU C Library versions 2.39 and older may overflow the output buffer passed to it by up to 4 bytes when converting strings to the ISO-2022-CN-EXT character set, which may be used to crash an application or overwrite a neighbouring variable. Solution(s) rocky-upgrade-compat-libpthread-nonshared rocky-upgrade-glibc rocky-upgrade-glibc-all-langpacks rocky-upgrade-glibc-all-langpacks-debuginfo rocky-upgrade-glibc-benchtests rocky-upgrade-glibc-benchtests-debuginfo rocky-upgrade-glibc-common rocky-upgrade-glibc-common-debuginfo rocky-upgrade-glibc-debuginfo rocky-upgrade-glibc-debugsource rocky-upgrade-glibc-devel rocky-upgrade-glibc-gconv-extra rocky-upgrade-glibc-gconv-extra-debuginfo rocky-upgrade-glibc-headers rocky-upgrade-glibc-langpack-aa rocky-upgrade-glibc-langpack-af rocky-upgrade-glibc-langpack-agr rocky-upgrade-glibc-langpack-ak rocky-upgrade-glibc-langpack-am rocky-upgrade-glibc-langpack-an rocky-upgrade-glibc-langpack-anp rocky-upgrade-glibc-langpack-ar rocky-upgrade-glibc-langpack-as rocky-upgrade-glibc-langpack-ast rocky-upgrade-glibc-langpack-ayc rocky-upgrade-glibc-langpack-az rocky-upgrade-glibc-langpack-be rocky-upgrade-glibc-langpack-bem rocky-upgrade-glibc-langpack-ber rocky-upgrade-glibc-langpack-bg rocky-upgrade-glibc-langpack-bhb rocky-upgrade-glibc-langpack-bho rocky-upgrade-glibc-langpack-bi rocky-upgrade-glibc-langpack-bn rocky-upgrade-glibc-langpack-bo rocky-upgrade-glibc-langpack-br rocky-upgrade-glibc-langpack-brx rocky-upgrade-glibc-langpack-bs rocky-upgrade-glibc-langpack-byn rocky-upgrade-glibc-langpack-ca rocky-upgrade-glibc-langpack-ce rocky-upgrade-glibc-langpack-chr rocky-upgrade-glibc-langpack-ckb rocky-upgrade-glibc-langpack-cmn rocky-upgrade-glibc-langpack-crh rocky-upgrade-glibc-langpack-cs rocky-upgrade-glibc-langpack-csb rocky-upgrade-glibc-langpack-cv rocky-upgrade-glibc-langpack-cy rocky-upgrade-glibc-langpack-da rocky-upgrade-glibc-langpack-de rocky-upgrade-glibc-langpack-doi rocky-upgrade-glibc-langpack-dsb rocky-upgrade-glibc-langpack-dv rocky-upgrade-glibc-langpack-dz rocky-upgrade-glibc-langpack-el rocky-upgrade-glibc-langpack-en rocky-upgrade-glibc-langpack-eo rocky-upgrade-glibc-langpack-es rocky-upgrade-glibc-langpack-et rocky-upgrade-glibc-langpack-eu rocky-upgrade-glibc-langpack-fa rocky-upgrade-glibc-langpack-ff rocky-upgrade-glibc-langpack-fi rocky-upgrade-glibc-langpack-fil rocky-upgrade-glibc-langpack-fo rocky-upgrade-glibc-langpack-fr rocky-upgrade-glibc-langpack-fur rocky-upgrade-glibc-langpack-fy rocky-upgrade-glibc-langpack-ga rocky-upgrade-glibc-langpack-gd rocky-upgrade-glibc-langpack-gez rocky-upgrade-glibc-langpack-gl rocky-upgrade-glibc-langpack-gu rocky-upgrade-glibc-langpack-gv rocky-upgrade-glibc-langpack-ha rocky-upgrade-glibc-langpack-hak rocky-upgrade-glibc-langpack-he rocky-upgrade-glibc-langpack-hi rocky-upgrade-glibc-langpack-hif rocky-upgrade-glibc-langpack-hne rocky-upgrade-glibc-langpack-hr rocky-upgrade-glibc-langpack-hsb rocky-upgrade-glibc-langpack-ht rocky-upgrade-glibc-langpack-hu rocky-upgrade-glibc-langpack-hy rocky-upgrade-glibc-langpack-ia rocky-upgrade-glibc-langpack-id rocky-upgrade-glibc-langpack-ig rocky-upgrade-glibc-langpack-ik rocky-upgrade-glibc-langpack-is rocky-upgrade-glibc-langpack-it rocky-upgrade-glibc-langpack-iu rocky-upgrade-glibc-langpack-ja rocky-upgrade-glibc-langpack-ka rocky-upgrade-glibc-langpack-kab rocky-upgrade-glibc-langpack-kk rocky-upgrade-glibc-langpack-kl rocky-upgrade-glibc-langpack-km rocky-upgrade-glibc-langpack-kn rocky-upgrade-glibc-langpack-ko rocky-upgrade-glibc-langpack-kok rocky-upgrade-glibc-langpack-ks rocky-upgrade-glibc-langpack-ku rocky-upgrade-glibc-langpack-kw rocky-upgrade-glibc-langpack-ky rocky-upgrade-glibc-langpack-lb rocky-upgrade-glibc-langpack-lg rocky-upgrade-glibc-langpack-li rocky-upgrade-glibc-langpack-lij rocky-upgrade-glibc-langpack-ln rocky-upgrade-glibc-langpack-lo rocky-upgrade-glibc-langpack-lt rocky-upgrade-glibc-langpack-lv rocky-upgrade-glibc-langpack-lzh rocky-upgrade-glibc-langpack-mag rocky-upgrade-glibc-langpack-mai rocky-upgrade-glibc-langpack-mfe rocky-upgrade-glibc-langpack-mg rocky-upgrade-glibc-langpack-mhr rocky-upgrade-glibc-langpack-mi rocky-upgrade-glibc-langpack-miq rocky-upgrade-glibc-langpack-mjw rocky-upgrade-glibc-langpack-mk rocky-upgrade-glibc-langpack-ml rocky-upgrade-glibc-langpack-mn rocky-upgrade-glibc-langpack-mni rocky-upgrade-glibc-langpack-mnw rocky-upgrade-glibc-langpack-mr rocky-upgrade-glibc-langpack-ms rocky-upgrade-glibc-langpack-mt rocky-upgrade-glibc-langpack-my rocky-upgrade-glibc-langpack-nan rocky-upgrade-glibc-langpack-nb rocky-upgrade-glibc-langpack-nds rocky-upgrade-glibc-langpack-ne rocky-upgrade-glibc-langpack-nhn rocky-upgrade-glibc-langpack-niu rocky-upgrade-glibc-langpack-nl rocky-upgrade-glibc-langpack-nn rocky-upgrade-glibc-langpack-nr rocky-upgrade-glibc-langpack-nso rocky-upgrade-glibc-langpack-oc rocky-upgrade-glibc-langpack-om rocky-upgrade-glibc-langpack-or rocky-upgrade-glibc-langpack-os rocky-upgrade-glibc-langpack-pa rocky-upgrade-glibc-langpack-pap rocky-upgrade-glibc-langpack-pl rocky-upgrade-glibc-langpack-ps rocky-upgrade-glibc-langpack-pt rocky-upgrade-glibc-langpack-quz rocky-upgrade-glibc-langpack-raj rocky-upgrade-glibc-langpack-ro rocky-upgrade-glibc-langpack-ru rocky-upgrade-glibc-langpack-rw rocky-upgrade-glibc-langpack-sa rocky-upgrade-glibc-langpack-sah rocky-upgrade-glibc-langpack-sat rocky-upgrade-glibc-langpack-sc rocky-upgrade-glibc-langpack-sd rocky-upgrade-glibc-langpack-se rocky-upgrade-glibc-langpack-sgs rocky-upgrade-glibc-langpack-shn rocky-upgrade-glibc-langpack-shs rocky-upgrade-glibc-langpack-si rocky-upgrade-glibc-langpack-sid rocky-upgrade-glibc-langpack-sk rocky-upgrade-glibc-langpack-sl rocky-upgrade-glibc-langpack-sm rocky-upgrade-glibc-langpack-so rocky-upgrade-glibc-langpack-sq rocky-upgrade-glibc-langpack-sr rocky-upgrade-glibc-langpack-ss rocky-upgrade-glibc-langpack-st rocky-upgrade-glibc-langpack-sv rocky-upgrade-glibc-langpack-sw rocky-upgrade-glibc-langpack-szl rocky-upgrade-glibc-langpack-ta rocky-upgrade-glibc-langpack-tcy rocky-upgrade-glibc-langpack-te rocky-upgrade-glibc-langpack-tg rocky-upgrade-glibc-langpack-th rocky-upgrade-glibc-langpack-the rocky-upgrade-glibc-langpack-ti rocky-upgrade-glibc-langpack-tig rocky-upgrade-glibc-langpack-tk rocky-upgrade-glibc-langpack-tl rocky-upgrade-glibc-langpack-tn rocky-upgrade-glibc-langpack-to rocky-upgrade-glibc-langpack-tpi rocky-upgrade-glibc-langpack-tr rocky-upgrade-glibc-langpack-ts rocky-upgrade-glibc-langpack-tt rocky-upgrade-glibc-langpack-ug rocky-upgrade-glibc-langpack-uk rocky-upgrade-glibc-langpack-unm rocky-upgrade-glibc-langpack-ur rocky-upgrade-glibc-langpack-uz rocky-upgrade-glibc-langpack-ve rocky-upgrade-glibc-langpack-vi rocky-upgrade-glibc-langpack-wa rocky-upgrade-glibc-langpack-wae rocky-upgrade-glibc-langpack-wal rocky-upgrade-glibc-langpack-wo rocky-upgrade-glibc-langpack-xh rocky-upgrade-glibc-langpack-yi rocky-upgrade-glibc-langpack-yo rocky-upgrade-glibc-langpack-yue rocky-upgrade-glibc-langpack-yuw rocky-upgrade-glibc-langpack-zh rocky-upgrade-glibc-langpack-zu rocky-upgrade-glibc-locale-source rocky-upgrade-glibc-minimal-langpack rocky-upgrade-glibc-nss-devel rocky-upgrade-glibc-static rocky-upgrade-glibc-utils rocky-upgrade-glibc-utils-debuginfo rocky-upgrade-libnsl rocky-upgrade-libnsl-debuginfo rocky-upgrade-nscd rocky-upgrade-nscd-debuginfo rocky-upgrade-nss_db rocky-upgrade-nss_db-debuginfo rocky-upgrade-nss_hesiod rocky-upgrade-nss_hesiod-debuginfo References https://attackerkb.com/topics/cve-2024-2961 CVE - 2024-2961 https://errata.rockylinux.org/RLSA-2024:2722 https://errata.rockylinux.org/RLSA-2024:3269 https://errata.rockylinux.org/RLSA-2024:3339
-
Debian: CVE-2024-31578: ffmpeg -- security update
Debian: CVE-2024-31578: ffmpeg -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/17/2024 Created 10/24/2024 Added 10/23/2024 Modified 10/23/2024 Description FFmpeg version n6.1.1 was discovered to contain a heap use-after-free via the av_hwframe_ctx_init function. Solution(s) debian-upgrade-ffmpeg References https://attackerkb.com/topics/cve-2024-31578 CVE - 2024-31578 DLA-3928-1
-
SUSE: CVE-2024-3847: SUSE Linux Security Advisory
SUSE: CVE-2024-3847: SUSE Linux Security Advisory Severity 6 CVSS (AV:N/AC:M/Au:N/C:P/I:P/A:N) Published 04/17/2024 Created 05/18/2024 Added 05/17/2024 Modified 01/28/2025 Description Insufficient policy enforcement in WebUI in Google Chrome prior to 124.0.6367.60 allowed a remote attacker to bypass content security policy via a crafted HTML page. (Chromium security severity: Low) Solution(s) suse-upgrade-opera References https://attackerkb.com/topics/cve-2024-3847 CVE - 2024-3847
-
Red Hat: CVE-2024-26882: kernel: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() (Multiple Advisories)
Red Hat: CVE-2024-26882: kernel: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/17/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() Apply the same fix than ones found in : 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. syzbot reported: BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26882 RHSA-2024:9315
-
Debian: CVE-2024-26837: linux -- security update
Debian: CVE-2024-26837: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/17/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FIDSTATEQF0123456789a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1static --0.......... 33:33:ff:87:e4:3f 1static --0.......... ff:ff:ff:ff:ff:ff 1static --0123456789a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-26837 CVE - 2024-26837
-
Oracle Linux: CVE-2024-26837: ELSA-2024-5101: kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-26837: ELSA-2024-5101:kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/17/2024 Created 08/20/2024 Added 08/16/2024 Modified 11/29/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FIDSTATEQF0123456789a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1static --0.......... 33:33:ff:87:e4:3f 1static --0.......... ff:ff:ff:ff:ff:ff 1static --0123456789a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions. A flaw was found in the Linux kernel. A race condition in network bridge management could lead to a denial of service. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2024-26837 CVE - 2024-26837 ELSA-2024-5101
-
Google Chrome Vulnerability: CVE-2024-3839 Out of bounds read in Fonts
Google Chrome Vulnerability: CVE-2024-3839 Out of bounds read in Fonts Severity 7 CVSS (AV:N/AC:M/Au:N/C:C/I:N/A:N) Published 04/17/2024 Created 04/17/2024 Added 04/17/2024 Modified 01/28/2025 Description Out of bounds read in Fonts in Google Chrome prior to 124.0.6367.60 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-3839 CVE - 2024-3839 https://chromereleases.googleblog.com/2024/04/stable-channel-update-for-desktop_16.html
-
Red Hat: CVE-2024-26846: kernel: nvme-fc: do not wait in vain when unloading module (Multiple Advisories)
Red Hat: CVE-2024-26846: kernel: nvme-fc: do not wait in vain when unloading module (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 04/17/2024 Created 09/26/2024 Added 09/25/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: nvme-fc: do not wait in vain when unloading module The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. This is done by flushing the nvme_delete_wq workqueue. While at it, remove the unused nvme_fc_wq workqueue too. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26846 RHSA-2024:7000 RHSA-2024:9315
-
Red Hat: CVE-2024-26855: kernel: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() (Multiple Advisories)
Red Hat: CVE-2024-26855: kernel: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 04/17/2024 Created 09/14/2024 Added 09/13/2024 Modified 01/09/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() The function ice_bridge_setlink() may encounter a NULL pointer dereference if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently in nla_for_each_nested(). To address this issue, add a check to ensure that br_spec is not NULL before proceeding with the nested attribute iteration. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26855 RHSA-2024:5364 RHSA-2024:5365 RHSA-2024:5928 RHSA-2024:7000 RHSA-2024:7001
-
Red Hat: CVE-2024-26857: kernel: geneve: make sure to pull inner header in geneve_rx() (Multiple Advisories)
Red Hat: CVE-2024-26857: kernel: geneve: make sure to pull inner header in geneve_rx() (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 04/17/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: geneve: make sure to pull inner header in geneve_rx() syzbot triggered a bug in geneve_rx() [1] Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. [1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26857 RHSA-2024:9315
-
SUSE: CVE-2024-26872: SUSE Linux Security Advisory
SUSE: CVE-2024-26872: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/17/2024 Created 05/15/2024 Added 05/15/2024 Modified 05/16/2024 Description In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete. Solution(s) suse-upgrade-cluster-md-kmp-64kb suse-upgrade-cluster-md-kmp-azure suse-upgrade-cluster-md-kmp-default suse-upgrade-cluster-md-kmp-rt suse-upgrade-dlm-kmp-64kb suse-upgrade-dlm-kmp-azure suse-upgrade-dlm-kmp-default suse-upgrade-dlm-kmp-rt suse-upgrade-dtb-allwinner suse-upgrade-dtb-altera suse-upgrade-dtb-amazon suse-upgrade-dtb-amd suse-upgrade-dtb-amlogic suse-upgrade-dtb-apm suse-upgrade-dtb-apple suse-upgrade-dtb-arm suse-upgrade-dtb-broadcom suse-upgrade-dtb-cavium suse-upgrade-dtb-exynos suse-upgrade-dtb-freescale suse-upgrade-dtb-hisilicon suse-upgrade-dtb-lg suse-upgrade-dtb-marvell suse-upgrade-dtb-mediatek suse-upgrade-dtb-nvidia suse-upgrade-dtb-qcom suse-upgrade-dtb-renesas suse-upgrade-dtb-rockchip suse-upgrade-dtb-socionext suse-upgrade-dtb-sprd suse-upgrade-dtb-xilinx suse-upgrade-gfs2-kmp-64kb suse-upgrade-gfs2-kmp-azure suse-upgrade-gfs2-kmp-default suse-upgrade-gfs2-kmp-rt suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-64kb-extra suse-upgrade-kernel-64kb-livepatch-devel suse-upgrade-kernel-64kb-optional suse-upgrade-kernel-azure suse-upgrade-kernel-azure-devel suse-upgrade-kernel-azure-extra suse-upgrade-kernel-azure-livepatch-devel suse-upgrade-kernel-azure-optional suse-upgrade-kernel-azure-vdso suse-upgrade-kernel-debug suse-upgrade-kernel-debug-devel suse-upgrade-kernel-debug-livepatch-devel suse-upgrade-kernel-debug-vdso suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-base-rebuild suse-upgrade-kernel-default-devel suse-upgrade-kernel-default-extra suse-upgrade-kernel-default-livepatch suse-upgrade-kernel-default-livepatch-devel suse-upgrade-kernel-default-optional suse-upgrade-kernel-default-vdso suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure suse-upgrade-kernel-devel-rt suse-upgrade-kernel-docs suse-upgrade-kernel-docs-html suse-upgrade-kernel-kvmsmall suse-upgrade-kernel-kvmsmall-devel suse-upgrade-kernel-kvmsmall-livepatch-devel suse-upgrade-kernel-kvmsmall-vdso suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-obs-qa suse-upgrade-kernel-rt suse-upgrade-kernel-rt-devel suse-upgrade-kernel-rt-extra suse-upgrade-kernel-rt-livepatch suse-upgrade-kernel-rt-livepatch-devel suse-upgrade-kernel-rt-optional suse-upgrade-kernel-rt-vdso suse-upgrade-kernel-rt_debug suse-upgrade-kernel-rt_debug-devel suse-upgrade-kernel-rt_debug-livepatch-devel suse-upgrade-kernel-rt_debug-vdso suse-upgrade-kernel-source suse-upgrade-kernel-source-azure suse-upgrade-kernel-source-rt suse-upgrade-kernel-source-vanilla suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-syms-rt suse-upgrade-kernel-zfcpdump suse-upgrade-kselftests-kmp-64kb suse-upgrade-kselftests-kmp-azure suse-upgrade-kselftests-kmp-default suse-upgrade-kselftests-kmp-rt suse-upgrade-ocfs2-kmp-64kb suse-upgrade-ocfs2-kmp-azure suse-upgrade-ocfs2-kmp-default suse-upgrade-ocfs2-kmp-rt suse-upgrade-reiserfs-kmp-64kb suse-upgrade-reiserfs-kmp-azure suse-upgrade-reiserfs-kmp-default suse-upgrade-reiserfs-kmp-rt References https://attackerkb.com/topics/cve-2024-26872 CVE - 2024-26872
-
Red Hat: CVE-2024-2961: glibc: Out of bounds write in iconv may lead to remote code execution (Multiple Advisories)
Red Hat: CVE-2024-2961: glibc: Out of bounds write in iconv may lead to remote code execution (Multiple Advisories) Severity 9 CVSS (AV:N/AC:L/Au:S/C:C/I:C/A:C) Published 04/17/2024 Created 05/10/2024 Added 05/09/2024 Modified 09/03/2024 Description The iconv() function in the GNU C Library versions 2.39 and older may overflow the output buffer passed to it by up to 4 bytes when converting strings to the ISO-2022-CN-EXT character set, which may be used to crash an application or overwrite a neighbouring variable. Solution(s) redhat-upgrade-compat-libpthread-nonshared redhat-upgrade-glibc redhat-upgrade-glibc-all-langpacks redhat-upgrade-glibc-all-langpacks-debuginfo redhat-upgrade-glibc-benchtests redhat-upgrade-glibc-benchtests-debuginfo redhat-upgrade-glibc-common redhat-upgrade-glibc-common-debuginfo redhat-upgrade-glibc-debuginfo redhat-upgrade-glibc-debuginfo-common redhat-upgrade-glibc-debugsource redhat-upgrade-glibc-devel redhat-upgrade-glibc-doc redhat-upgrade-glibc-gconv-extra redhat-upgrade-glibc-gconv-extra-debuginfo redhat-upgrade-glibc-headers redhat-upgrade-glibc-langpack-aa redhat-upgrade-glibc-langpack-af redhat-upgrade-glibc-langpack-agr redhat-upgrade-glibc-langpack-ak redhat-upgrade-glibc-langpack-am redhat-upgrade-glibc-langpack-an redhat-upgrade-glibc-langpack-anp redhat-upgrade-glibc-langpack-ar redhat-upgrade-glibc-langpack-as redhat-upgrade-glibc-langpack-ast redhat-upgrade-glibc-langpack-ayc redhat-upgrade-glibc-langpack-az redhat-upgrade-glibc-langpack-be redhat-upgrade-glibc-langpack-bem redhat-upgrade-glibc-langpack-ber redhat-upgrade-glibc-langpack-bg redhat-upgrade-glibc-langpack-bhb redhat-upgrade-glibc-langpack-bho redhat-upgrade-glibc-langpack-bi redhat-upgrade-glibc-langpack-bn redhat-upgrade-glibc-langpack-bo redhat-upgrade-glibc-langpack-br redhat-upgrade-glibc-langpack-brx redhat-upgrade-glibc-langpack-bs redhat-upgrade-glibc-langpack-byn redhat-upgrade-glibc-langpack-ca redhat-upgrade-glibc-langpack-ce redhat-upgrade-glibc-langpack-chr redhat-upgrade-glibc-langpack-ckb redhat-upgrade-glibc-langpack-cmn redhat-upgrade-glibc-langpack-crh redhat-upgrade-glibc-langpack-cs redhat-upgrade-glibc-langpack-csb redhat-upgrade-glibc-langpack-cv redhat-upgrade-glibc-langpack-cy redhat-upgrade-glibc-langpack-da redhat-upgrade-glibc-langpack-de redhat-upgrade-glibc-langpack-doi redhat-upgrade-glibc-langpack-dsb redhat-upgrade-glibc-langpack-dv redhat-upgrade-glibc-langpack-dz redhat-upgrade-glibc-langpack-el redhat-upgrade-glibc-langpack-en redhat-upgrade-glibc-langpack-eo redhat-upgrade-glibc-langpack-es redhat-upgrade-glibc-langpack-et redhat-upgrade-glibc-langpack-eu redhat-upgrade-glibc-langpack-fa redhat-upgrade-glibc-langpack-ff redhat-upgrade-glibc-langpack-fi redhat-upgrade-glibc-langpack-fil redhat-upgrade-glibc-langpack-fo redhat-upgrade-glibc-langpack-fr redhat-upgrade-glibc-langpack-fur redhat-upgrade-glibc-langpack-fy redhat-upgrade-glibc-langpack-ga redhat-upgrade-glibc-langpack-gd redhat-upgrade-glibc-langpack-gez redhat-upgrade-glibc-langpack-gl redhat-upgrade-glibc-langpack-gu redhat-upgrade-glibc-langpack-gv redhat-upgrade-glibc-langpack-ha redhat-upgrade-glibc-langpack-hak redhat-upgrade-glibc-langpack-he redhat-upgrade-glibc-langpack-hi redhat-upgrade-glibc-langpack-hif redhat-upgrade-glibc-langpack-hne redhat-upgrade-glibc-langpack-hr redhat-upgrade-glibc-langpack-hsb redhat-upgrade-glibc-langpack-ht redhat-upgrade-glibc-langpack-hu redhat-upgrade-glibc-langpack-hy redhat-upgrade-glibc-langpack-ia redhat-upgrade-glibc-langpack-id redhat-upgrade-glibc-langpack-ig redhat-upgrade-glibc-langpack-ik redhat-upgrade-glibc-langpack-is redhat-upgrade-glibc-langpack-it redhat-upgrade-glibc-langpack-iu redhat-upgrade-glibc-langpack-ja redhat-upgrade-glibc-langpack-ka redhat-upgrade-glibc-langpack-kab redhat-upgrade-glibc-langpack-kk redhat-upgrade-glibc-langpack-kl redhat-upgrade-glibc-langpack-km redhat-upgrade-glibc-langpack-kn redhat-upgrade-glibc-langpack-ko redhat-upgrade-glibc-langpack-kok redhat-upgrade-glibc-langpack-ks redhat-upgrade-glibc-langpack-ku redhat-upgrade-glibc-langpack-kw redhat-upgrade-glibc-langpack-ky redhat-upgrade-glibc-langpack-lb redhat-upgrade-glibc-langpack-lg redhat-upgrade-glibc-langpack-li redhat-upgrade-glibc-langpack-lij redhat-upgrade-glibc-langpack-ln redhat-upgrade-glibc-langpack-lo redhat-upgrade-glibc-langpack-lt redhat-upgrade-glibc-langpack-lv redhat-upgrade-glibc-langpack-lzh redhat-upgrade-glibc-langpack-mag redhat-upgrade-glibc-langpack-mai redhat-upgrade-glibc-langpack-mfe redhat-upgrade-glibc-langpack-mg redhat-upgrade-glibc-langpack-mhr redhat-upgrade-glibc-langpack-mi redhat-upgrade-glibc-langpack-miq redhat-upgrade-glibc-langpack-mjw redhat-upgrade-glibc-langpack-mk redhat-upgrade-glibc-langpack-ml redhat-upgrade-glibc-langpack-mn redhat-upgrade-glibc-langpack-mni redhat-upgrade-glibc-langpack-mnw redhat-upgrade-glibc-langpack-mr redhat-upgrade-glibc-langpack-ms redhat-upgrade-glibc-langpack-mt redhat-upgrade-glibc-langpack-my redhat-upgrade-glibc-langpack-nan redhat-upgrade-glibc-langpack-nb redhat-upgrade-glibc-langpack-nds redhat-upgrade-glibc-langpack-ne redhat-upgrade-glibc-langpack-nhn redhat-upgrade-glibc-langpack-niu redhat-upgrade-glibc-langpack-nl redhat-upgrade-glibc-langpack-nn redhat-upgrade-glibc-langpack-nr redhat-upgrade-glibc-langpack-nso redhat-upgrade-glibc-langpack-oc redhat-upgrade-glibc-langpack-om redhat-upgrade-glibc-langpack-or redhat-upgrade-glibc-langpack-os redhat-upgrade-glibc-langpack-pa redhat-upgrade-glibc-langpack-pap redhat-upgrade-glibc-langpack-pl redhat-upgrade-glibc-langpack-ps redhat-upgrade-glibc-langpack-pt redhat-upgrade-glibc-langpack-quz redhat-upgrade-glibc-langpack-raj redhat-upgrade-glibc-langpack-ro redhat-upgrade-glibc-langpack-ru redhat-upgrade-glibc-langpack-rw redhat-upgrade-glibc-langpack-sa redhat-upgrade-glibc-langpack-sah redhat-upgrade-glibc-langpack-sat redhat-upgrade-glibc-langpack-sc redhat-upgrade-glibc-langpack-sd redhat-upgrade-glibc-langpack-se redhat-upgrade-glibc-langpack-sgs redhat-upgrade-glibc-langpack-shn redhat-upgrade-glibc-langpack-shs redhat-upgrade-glibc-langpack-si redhat-upgrade-glibc-langpack-sid redhat-upgrade-glibc-langpack-sk redhat-upgrade-glibc-langpack-sl redhat-upgrade-glibc-langpack-sm redhat-upgrade-glibc-langpack-so redhat-upgrade-glibc-langpack-sq redhat-upgrade-glibc-langpack-sr redhat-upgrade-glibc-langpack-ss redhat-upgrade-glibc-langpack-st redhat-upgrade-glibc-langpack-sv redhat-upgrade-glibc-langpack-sw redhat-upgrade-glibc-langpack-szl redhat-upgrade-glibc-langpack-ta redhat-upgrade-glibc-langpack-tcy redhat-upgrade-glibc-langpack-te redhat-upgrade-glibc-langpack-tg redhat-upgrade-glibc-langpack-th redhat-upgrade-glibc-langpack-the redhat-upgrade-glibc-langpack-ti redhat-upgrade-glibc-langpack-tig redhat-upgrade-glibc-langpack-tk redhat-upgrade-glibc-langpack-tl redhat-upgrade-glibc-langpack-tn redhat-upgrade-glibc-langpack-to redhat-upgrade-glibc-langpack-tpi redhat-upgrade-glibc-langpack-tr redhat-upgrade-glibc-langpack-ts redhat-upgrade-glibc-langpack-tt redhat-upgrade-glibc-langpack-ug redhat-upgrade-glibc-langpack-uk redhat-upgrade-glibc-langpack-unm redhat-upgrade-glibc-langpack-ur redhat-upgrade-glibc-langpack-uz redhat-upgrade-glibc-langpack-ve redhat-upgrade-glibc-langpack-vi redhat-upgrade-glibc-langpack-wa redhat-upgrade-glibc-langpack-wae redhat-upgrade-glibc-langpack-wal redhat-upgrade-glibc-langpack-wo redhat-upgrade-glibc-langpack-xh redhat-upgrade-glibc-langpack-yi redhat-upgrade-glibc-langpack-yo redhat-upgrade-glibc-langpack-yue redhat-upgrade-glibc-langpack-yuw redhat-upgrade-glibc-langpack-zh redhat-upgrade-glibc-langpack-zu redhat-upgrade-glibc-locale-source redhat-upgrade-glibc-minimal-langpack redhat-upgrade-glibc-nss-devel redhat-upgrade-glibc-static redhat-upgrade-glibc-utils redhat-upgrade-glibc-utils-debuginfo redhat-upgrade-libnsl redhat-upgrade-libnsl-debuginfo redhat-upgrade-nscd redhat-upgrade-nscd-debuginfo redhat-upgrade-nss_db redhat-upgrade-nss_db-debuginfo redhat-upgrade-nss_hesiod redhat-upgrade-nss_hesiod-debuginfo References CVE-2024-2961 RHSA-2024:2722 RHSA-2024:2799 RHSA-2024:3269 RHSA-2024:3312 RHSA-2024:3339 RHSA-2024:3411 RHSA-2024:3423 RHSA-2024:3588 View more
-
Red Hat: CVE-2024-26872: kernel: RDMA/srpt: Do not register event handler until srpt device is fully setup (Multiple Advisories)
Red Hat: CVE-2024-26872: kernel: RDMA/srpt: Do not register event handler until srpt device is fully setup (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 04/17/2024 Created 06/07/2024 Added 06/06/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26872 RHSA-2024:3618 RHSA-2024:3627 RHSA-2024:9315
-
Red Hat: CVE-2024-26880: kernel: dm: call the resume method on internal suspend (Multiple Advisories)
Red Hat: CVE-2024-26880: kernel: dm: call the resume method on internal suspend (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 04/17/2024 Created 07/26/2024 Added 07/25/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: dm: call the resume method on internal suspend There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the origin_postsuspend function. The second call attempts to remove the "hash_list" entry from a list, while it was already removed by the first call. Fix __dm_internal_resume so that it calls the preresume and resume methods of the table's targets. If a preresume method of some target fails, we are in a tricky situation. We can't return an error because dm_internal_resume isn't supposed to return errors. We can't return success, because then the "resume" and "postsuspend" methods would not be paired correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools, but it won't cause a kernel crash. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0 <snip> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0 FS:00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS:0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Call Trace: <TASK> ? die+0x2d/0x80 ? do_trap+0xeb/0xf0 ? __list_del_entry_valid_or_report+0x77/0xc0 ? do_error_trap+0x60/0x80 ? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60 ? __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20 ? table_deps+0x1b0/0x1b0 [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot] dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0 [dm_mod] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10 [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0xf7e6aead <snip> ---[ end trace 0000000000000000 ]--- Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26880 RHSA-2024:4823 RHSA-2024:4831 RHSA-2024:4928 RHSA-2024:7000 RHSA-2024:7001
-
Red Hat: CVE-2024-26886: kernel: Bluetooth: af_bluetooth: Fix deadlock (Multiple Advisories)
Red Hat: CVE-2024-26886: kernel: Bluetooth: af_bluetooth: Fix deadlock (Multiple Advisories) Severity 5 CVSS (AV:N/AC:H/Au:S/C:N/I:N/A:C) Published 04/17/2024 Created 09/20/2024 Added 09/19/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: Bluetooth: af_bluetooth: Fix deadlock Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26886 RHSA-2024:6567 RHSA-2024:6744 RHSA-2024:6745
-
Red Hat: CVE-2024-26889: kernel: Bluetooth: hci_core: Fix possible buffer overflow (Multiple Advisories)
Red Hat: CVE-2024-26889: kernel: Bluetooth: hci_core: Fix possible buffer overflow (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/17/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix possible buffer overflow struct hci_dev_info has a fixed size name[8] field so in the event that hdev->name is bigger than that strcpy would attempt to write past its size, so this fixes this problem by switching to use strscpy. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26889 RHSA-2024:9315
-
Red Hat: CVE-2024-26901: kernel: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak (Multiple Advisories)
Red Hat: CVE-2024-26901: kernel: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/17/2024 Created 06/07/2024 Added 06/06/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26901 RHSA-2024:3618 RHSA-2024:3627 RHSA-2024:9315
-
Ubuntu: (Multiple Advisories) (CVE-2024-26866): Linux kernel vulnerabilities
Ubuntu: (Multiple Advisories) (CVE-2024-26866): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/17/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: spi: lpspi: Avoid potential use-after-free in probe() fsl_lpspi_probe() is allocating/disposing memory manually with spi_alloc_host()/spi_alloc_target(), but uses devm_spi_register_controller(). In case of error after the latter call the memory will be explicitly freed in the probe function by spi_controller_put() call, but used afterwards by "devm" management outside probe() (spi_unregister_controller() <- devm_spi_unregister() below). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 ... Call trace: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release_all really_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach device_initial_probe bus_probe_device deferred_probe_work_func process_one_work worker_thread kthread ret_from_fork Solution(s) ubuntu-upgrade-linux-image-6-8-0-1004-gke ubuntu-upgrade-linux-image-6-8-0-1005-raspi ubuntu-upgrade-linux-image-6-8-0-1006-ibm ubuntu-upgrade-linux-image-6-8-0-1006-oem ubuntu-upgrade-linux-image-6-8-0-1006-oracle ubuntu-upgrade-linux-image-6-8-0-1006-oracle-64k ubuntu-upgrade-linux-image-6-8-0-1008-azure ubuntu-upgrade-linux-image-6-8-0-1008-azure-fde ubuntu-upgrade-linux-image-6-8-0-1008-gcp ubuntu-upgrade-linux-image-6-8-0-1009-aws ubuntu-upgrade-linux-image-6-8-0-35-generic ubuntu-upgrade-linux-image-6-8-0-35-generic-64k ubuntu-upgrade-linux-image-6-8-0-35-lowlatency ubuntu-upgrade-linux-image-6-8-0-35-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-24-04 ubuntu-upgrade-linux-image-generic-hwe-24-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-classic ubuntu-upgrade-linux-image-ibm-lts-24-04 ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-oem-24-04 ubuntu-upgrade-linux-image-oem-24-04a ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-24-04 References https://attackerkb.com/topics/cve-2024-26866 CVE - 2024-26866 USN-6816-1 USN-6817-1 USN-6817-2 USN-6817-3 USN-6878-1