In the Linux kernel, the following vulnerability has been resolved: ionic: fix kernel panic in XDP_TX action In the XDP_TX path, ionic driver sends a packet to the TX path with rx page and corresponding dma address. After tx is done, ionic_tx_clean() frees that page. But RX ring buffer isn't reset to NULL. So, it uses a freed page, which causes kernel panic. BUG: unable to handle page fault for address: ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Oops: Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comm: ksoftirqd/1 Not tainted 6.9.0+ #11 Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f Code: 00 53 41 55 41 56 41 57 b8 01 00 00 00 48 8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX: 0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048 RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09: ffffed1027a04a23 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100 R15: 00000001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x254/0x790 ? __pfx_page_fault_oops+0x10/0x10 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? search_bpf_extables+0x165/0x260 ? fixup_exception+0x4a/0x970 ? exc_page_fault+0xcb/0xe0 ? asm_exc_page_fault+0x22/0x30 ? 0xffffffffc0051f64 ? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f ? do_raw_spin_unlock+0x54/0x220 ionic_rx_service+0x11ab/0x3010 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_clean+0x29b/0xc60 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_tx_clean+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_cq_service+0x25d/0xa00 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_cq_service+0x69/0x150 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_txrx_napi+0x11a/0x540 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x7e7/0xc30 ? __pfx_net_rx_action+0x10/0x10

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-516.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer     corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented     packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to     calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing     changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in     rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.
    (CVE-2024-38586)

  - In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Avoid unnecessary     destruction of file_ida file_ida is allocated during cdev open and is freed accordingly during cdev     release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an     already empty file_ida when the WQ cdev is removed. Worse, ida_free() in cdev release may happen after     destruction of file_ida per WQ cdev. This can lead to accessing an id in file_ida after it has been     destroyed, resulting in a kernel panic. Remove ida_destroy(&file_ida) to address these issues.
    (CVE-2024-38629)

  - In the Linux kernel, the following vulnerability has been resolved: ionic: fix kernel panic in XDP_TX     action In the XDP_TX path, ionic driver sends a packet to the TX path with rx page and corresponding dma     address. After tx is done, ionic_tx_clean() frees that page. But RX ring buffer isn't reset to NULL. So,     it uses a freed page, which causes kernel panic. BUG: unable to handle page fault for address:
    ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Oops: Oops:
    0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comm: ksoftirqd/1 Not tainted 6.9.0+ #11     Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP:
    0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f Code: 00 53 41 55 41 56 41 57 b8 01 00 00 00 48     8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX:
    0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048     RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09: ffffed1027a04a23 R10:
    0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100     R15: 00000001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0     PKRU: 55555554 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x254/0x790 ?
    __pfx_page_fault_oops+0x10/0x10 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ?     search_bpf_extables+0x165/0x260 ? fixup_exception+0x4a/0x970 ? exc_page_fault+0xcb/0xe0 ?     asm_exc_page_fault+0x22/0x30 ? 0xffffffffc0051f64 ? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f     ? do_raw_spin_unlock+0x54/0x220 ionic_rx_service+0x11ab/0x3010 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_clean+0x29b/0xc60 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_tx_clean+0x10/0x10 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_cq_service+0x25d/0xa00 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_cq_service+0x69/0x150 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_txrx_napi+0x11a/0x540 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x7e7/0xc30 ?
    __pfx_net_rx_action+0x10/0x10 (CVE-2024-40907)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix missing lock on sync     reset reload On sync reset reload work, when remote host updates devlink on reload actions performed on     that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which     results in triggering lock assert like the following: WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261     devl_assert_locked+0x3e/0x50  CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116     Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events     mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50  Call Trace: <TASK> ?
    __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ?     exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? devl_assert_locked+0x3e/0x50     devlink_notify+0x88/0x2b0 ? mlx5_attach_device+0x20c/0x230 [mlx5_core] ? __pfx_devlink_notify+0x10/0x10 ?     process_one_work+0x4b6/0xbb0 process_one_work+0x4b6/0xbb0 [] (CVE-2024-42268)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: Return non-zero value from     tipc_udp_addr2str() on error tipc_udp_addr2str() should return non-zero value if the UDP media address is     invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning     1 on an invalid UDP media address. (CVE-2024-42284)

  - In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in     dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for     reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation.
    Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and     add it to the devres list. If this happens, there will be two entries in the devres list with the same     vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by     destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption     http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 (CVE-2024-43856)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix CT entry update leaks     of modify header context The cited commit allocates a new modify header to replace the old one when     updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support,     modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify     header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fix it by     restoring the old attr to attr when failed to allocate a new modify header context. So when the CT entry     is freed, the right modify header context will be freed. And the panic of accessing error pointer is also     fixed. (CVE-2024-43864)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in     shutdown callback There is no point in recovery during device shutdown. if health work started need to     wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback.
    (CVE-2024-43866)

  - In the Linux kernel, the following vulnerability has been resolved: memcg: protect concurrent access to     mem_cgroup_idr Commit 73f576c04b94 (mm: memcontrol: fix cgroup creation failure after many small jobs)     decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to     maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For     the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected     through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not     protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt     to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a     long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del()     and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the     super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were     either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed     to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases.
    Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr     and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So,     the most reasonable explanation is that these situations can happen due to race between multiple     idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing     multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the     system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing     list_lru_one. (CVE-2024-43892)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix invalid WQ     linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ     linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the     same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the     same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without     unlinking the WQE again. (CVE-2024-44970)

  - In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix double DMA unmapping for     XDP_REDIRECT Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should     have been removed when we let the page pool handle the DMA mapping. This bug causes the warning: WARNING:
    CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm:
    ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS     2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4     08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08     5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX:
    0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000     RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10:
    ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000     R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0     ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ?     handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ?     iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ?     bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en]     bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en]
    __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0 (CVE-2024-44984)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix validity interception     issue when gisa is switched off We might run into a SIE validity if gisa has been disabled either via     using kernel parameter kvm.use_gisa=0 or by setting the related sysfs attribute to N (echo N     >/sys/module/kvm/parameters/use_gisa). The validity is caused by an invalid value in the SIE control     block's gisa designation. That happens because we pass the uninitialized gisa origin to virt_to_phys()     before writing it to the gisa designation. To fix this we return 0 in kvm_s390_get_gisa_desc() if the     origin is 0. kvm_s390_get_gisa_desc() is used to determine which gisa designation to set in the SIE     control block. A value of 0 in the gisa designation disables gisa usage. The issue surfaces in the host     kernel with the following kernel message as soon a new kvm guest start is attemted. kvm: unhandled     validity intercept 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101     kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE     xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core     irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm 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 sunrpc mlx5_ib ib_uverbs     ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel     drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390     prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390     sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc     scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm:
    CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW :
    0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1     W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028     000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000     000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e     00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118:
    c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea     lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1     000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call     Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>]     kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm]     [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430     [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70     [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0     [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>]
    __warn_printk+0xe8/0xf0 (CVE-2024-45005)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
210815	RHEL 9 : kernel (RHSA-2024:9315)	Nessus	Red Hat Local Security Checks	high
208962	CentOS 9 : kernel-5.14.0-516.el9	Nessus	CentOS Local Security Checks	high

Detections

Analytics

CVE-2024-40907

medium

Tenable Plugins

high

high