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

  - Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
    (CVE-2023-52651)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring: drop any code related to     SCM_RIGHTS This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of     it. (CVE-2023-52656)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921e: fix use-after-     free in free_irq() From commit a304e1b82808 ([PATCH] Debug shared irqs), there is a test to make sure     the shared irq handler should be able to handle the unexpected event after deregistration. For this case,     let's apply MT76_REMOVED flag to indicate the device was removed and do not run into the resource access     anymore. BUG: KASAN: use-after-free in mt7921_irq_handler+0xd8/0x100 [mt7921e] Read of size 8 at addr     ffff88824a7d3b78 by task rmmod/11115 CPU: 28 PID: 11115 Comm: rmmod Tainted: G W L 5.17.0 #10 Hardware     name: Micro-Star International Co., Ltd. MS-7D73/MPG B650I EDGE WIFI (MS-7D73), BIOS 1.81 01/05/2024 Call     Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x1f/0x190 ?     mt7921_irq_handler+0xd8/0x100 [mt7921e] ? mt7921_irq_handler+0xd8/0x100 [mt7921e]     kasan_report.cold+0x7f/0x11b ? mt7921_irq_handler+0xd8/0x100 [mt7921e] mt7921_irq_handler+0xd8/0x100     [mt7921e] free_irq+0x627/0xaa0 devm_free_irq+0x94/0xd0 ? devm_request_any_context_irq+0x160/0x160 ?     kobject_put+0x18d/0x4a0 mt7921_pci_remove+0x153/0x190 [mt7921e] pci_device_remove+0xa2/0x1d0
    __device_release_driver+0x346/0x6e0 driver_detach+0x1ef/0x2c0 bus_remove_driver+0xe7/0x2d0 ?
    __check_object_size+0x57/0x310 pci_unregister_driver+0x26/0x250 __do_sys_delete_module+0x307/0x510 ?     free_module+0x6a0/0x6a0 ? fpregs_assert_state_consistent+0x4b/0xb0 ? rcu_read_lock_sched_held+0x10/0x70 ?     syscall_enter_from_user_mode+0x20/0x70 ? trace_hardirqs_on+0x1c/0x130 do_syscall_64+0x5c/0x80 ?     trace_hardirqs_on_prepare+0x72/0x160 ? do_syscall_64+0x68/0x80 ? trace_hardirqs_on_prepare+0x72/0x160     entry_SYSCALL_64_after_hwframe+0x44/0xae (CVE-2024-26892)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: delay all of     ath9k_wmi_event_tasklet() until init is complete The ath9k_wmi_event_tasklet() used in ath9k_htc assumes     that all the data structures have been fully initialised by the time it runs. However, because of the     order in which things are initialised, this is not guaranteed to be the case, because the device is     exposed to the USB subsystem before the ath9k driver initialisation is completed. We already committed a     partial fix for this in commit: 8b3046abc99e (ath9k_htc: fix NULL pointer dereference at     ath9k_htc_tx_get_packet()) However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the     event tasklet, pairing it with an initialisation complete bit in the TX struct. It seems syzbot managed     to trigger the race for one of the other commands as well, so let's just move the existing synchronisation     bit to cover the whole tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside     ath9k_tx_init()). (CVE-2024-26897)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: brcm80211: handle pmk_op     allocation failure The kzalloc() in brcmf_pmksa_v3_op() will return null if the physical memory has run     out. As a result, if we dereference the null value, the null pointer dereference bug will happen. Return
    -ENOMEM from brcmf_pmksa_v3_op() if kzalloc() fails for pmk_op. (CVE-2024-27048)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925e: fix use-after-     free in free_irq() From commit a304e1b82808 ([PATCH] Debug shared irqs), there is a test to make sure     the shared irq handler should be able to handle the unexpected event after deregistration. For this case,     let's apply MT76_REMOVED flag to indicate the device was removed and do not run into the resource access     anymore. (CVE-2024-27049)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: rtl8xxxu: add cancel_work_sync()     for c2hcmd_work The workqueue might still be running, when the driver is stopped. To avoid a use-after-     free, call cancel_work_sync() in rtl8xxxu_stop(). (CVE-2024-27052)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't set the MFP     flag for the GTK The firmware doesn't need the MFP flag for the GTK, it can even make the firmware crash.
    in case the AP is configured with: group cipher TKIP and MFPC. We would send the GTK with cipher = TKIP     and MFP which is of course not possible. (CVE-2024-27434)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check/clear fast rx     for non-4addr sta VLAN changes When moving a station out of a VLAN and deleting the VLAN afterwards, the     fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by     immediately calling ieee80211_check_fast_rx after the VLAN change. (CVE-2024-35789)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dbg-tlv: ensure NUL     termination The iwl_fw_ini_debug_info_tlv is used as a string, so we must ensure the string is terminated     correctly before using it. (CVE-2024-35845)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: rfi: fix potential     response leaks If the rx payload length check fails, or if kmemdup() fails, we still need to free the     command response. Fix that. (CVE-2024-35912)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: pick the version     of SESSION_PROTECTION_NOTIF When we want to know whether we should look for the mac_id or the link_id in     struct iwl_mvm_session_prot_notif, we should look at the version of SESSION_PROTECTION_NOTIF. This causes     WARNINGs: WARNING: CPU: 0 PID: 11403 at drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:959     iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] RIP:
    0010:iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] Code: 00 49 c7 84 24 48 07 00 00 00 00 00 00 41     c6 84 24 78 07 00 00 ff 4c 89 f7 e8 e9 71 54 d9 e9 7d fd ff ff 0f 0b e9 23 fe ff ff <0f> 0b e9 1c fe ff ff     66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffb4bb00003d40 EFLAGS: 00010202 RAX:
    0000000000000000 RBX: ffff9ae63a361000 RCX: ffff9ae4a98b60d4 RDX: ffff9ae4588499c0 RSI: 0000000000000305     RDI: ffff9ae4a98b6358 RBP: ffffb4bb00003d68 R08: 0000000000000003 R09: 0000000000000010 R10:
    ffffb4bb00003d00 R11: 000000000000000f R12: ffff9ae441399050 R13: ffff9ae4761329e8 R14: 0000000000000001     R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9ae7af400000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fb75680018 CR3: 00000003dae32006 CR4: 0000000000f70ef0     PKRU: 55555554 Call Trace: <IRQ> ? show_regs+0x69/0x80 ? __warn+0x8d/0x150 ?     iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] ? report_bug+0x196/0x1c0 ? handle_bug+0x45/0x80 ?     exc_invalid_op+0x1c/0xb0 ? asm_exc_invalid_op+0x1f/0x30 ? iwl_mvm_rx_session_protect_notif+0x333/0x340     [iwlmvm] iwl_mvm_rx_common+0x115/0x340 [iwlmvm] iwl_mvm_rx_mq+0xa6/0x100 [iwlmvm]     iwl_pcie_rx_handle+0x263/0xa10 [iwlwifi] iwl_pcie_napi_poll_msix+0x32/0xd0 [iwlwifi] (CVE-2024-35913)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: check A-MSDU format     more carefully If it looks like there's another subframe in the A-MSDU but the header isn't fully there,     we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if     the subframe header can even be present. (CVE-2024-35937)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: decrease MHI channel     buffer length to 8KB Currently buf_len field of ath11k_mhi_config_qca6390 is assigned with 0, making MHI     use a default size, 64KB, to allocate channel buffers. This is likely to fail in some scenarios where     system memory is highly fragmented and memory compaction or reclaim is not allowed. There is a fail report     which is caused by it: kworker/u32:45: page allocation failure: order:4,     mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 19318 Comm:
    kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased)     493b6d5b382c603654d7a81fc3c144d59a1dfceb Workqueue: events_unbound async_run_entry_fn Call Trace: <TASK>     dump_stack_lvl+0x47/0x60 warn_alloc+0x13a/0x1b0 ? srso_alias_return_thunk+0x5/0xfbef5 ?
    __alloc_pages_direct_compact+0xab/0x210 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0
    __alloc_pages+0x32d/0x350 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
    __kmalloc_large_node+0x72/0x110 __kmalloc+0x37c/0x480 ? mhi_map_single_no_bb+0x77/0xf0 [mhi     40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? mhi_prepare_channel+0x127/0x2d0 [mhi     40df44e07c05479f7a6e7b90fba9f0e0031a7814] mhi_prepare_channel+0x127/0x2d0 [mhi     40df44e07c05479f7a6e7b90fba9f0e0031a7814] __mhi_prepare_for_transfer+0x44/0x80 [mhi     40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi     40df44e07c05479f7a6e7b90fba9f0e0031a7814] device_for_each_child+0x5c/0xa0 ? __pfx_pci_pm_resume+0x10/0x10     ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e] ?     srso_alias_return_thunk+0x5/0xfbef5 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci     830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec] ? srso_alias_return_thunk+0x5/0xfbef5     dpm_run_callback+0x8c/0x1e0 device_resume+0x104/0x340 ? __pfx_dpm_watchdog_handler+0x10/0x10     async_resume+0x1d/0x30 async_run_entry_fn+0x32/0x120 process_one_work+0x168/0x330     worker_thread+0x2f5/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe8/0x120 ? __pfx_kthread+0x10/0x10     ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Actually those     buffers are used only by QMI target -> host communication. And for WCN6855 and QCA6390, the largest packet     size for that is less than 6KB. So change buf_len field to 8KB, which results in order 1 allocation if     page size is 4KB. In this way, we can at least save some memory, and as well as decrease the possibility     of allocation failure in those scenarios. Tested-on: WCN6855 hw2.0 PCI     WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 (CVE-2024-35938)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix null pointer access     when abort scan During cancel scan we might use vif that weren't scanning. Fix this by using the actual     scanning vif. (CVE-2024-35946)

  - In the Linux kernel, the following vulnerability has been resolved: mm: use memalloc_nofs_save() in     page_cache_ra_order() See commit f2c817bed58d (mm: use memalloc_nofs_save in readahead path), ensure     that page_cache_ra_order() do not attempt to reclaim file-backed pages too, or it leads to a deadlock,     found issue when test ext4 large folio. INFO: task DataXceiver for:7494 blocked for more than 120 seconds.
    echo 0 > /proc/sys/kernel/hung_task_timeout_secs disables this message. task:DataXceiver for state:D     stack:0 pid:7494 ppid:1 flags:0x00000200 Call trace: __switch_to+0x14c/0x240 __schedule+0x82c/0xdd0     schedule+0x58/0xf0 io_schedule+0x24/0xa0 __folio_lock+0x130/0x300 migrate_pages_batch+0x378/0x918     migrate_pages+0x350/0x700 compact_zone+0x63c/0xb38 compact_zone_order+0xc0/0x118     try_to_compact_pages+0xb0/0x280 __alloc_pages_direct_compact+0x98/0x248 __alloc_pages+0x510/0x1110     alloc_pages+0x9c/0x130 folio_alloc+0x20/0x78 filemap_alloc_folio+0x8c/0x1b0     page_cache_ra_order+0x174/0x308 ondemand_readahead+0x1c8/0x2b8 page_cache_async_ra+0x68/0xb8     filemap_readahead.isra.0+0x64/0xa8 filemap_get_pages+0x3fc/0x5b0 filemap_splice_read+0xf4/0x280     ext4_file_splice_read+0x2c/0x48 [ext4] vfs_splice_read.part.0+0xa8/0x118 splice_direct_to_actor+0xbc/0x288     do_splice_direct+0x9c/0x108 do_sendfile+0x328/0x468 __arm64_sys_sendfile64+0x8c/0x148     invoke_syscall+0x4c/0x118 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x4c/0x1f8     el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188/0x190 (CVE-2024-36882)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: guard against     invalid STA ID on removal Guard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would result     in out-of-bounds array accesses. This prevents issues should the driver get into a bad state during error     handling. (CVE-2024-36921)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr     under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock,     and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in     the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock. (CVE-2024-36922)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: don't free NULL     coalescing rule If the parsing fails, we can dereference a NULL pointer here. (CVE-2024-36941)

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	Published	Updated	Severity
201993	CentOS 9 : kernel-5.14.0-474.el9	Nessus	CentOS Local Security Checks	7/9/2024	7/9/2024	critical
200853	SUSE SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:2135-1)	Nessus	SuSE Local Security Checks	6/22/2024	6/22/2024	high

Detections

Analytics

Plugins Search

critical

high