CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1792976962)

high Nessus Plugin ID 374124

Language:

Synopsis

The CentOS Linux host is missing one or more security updates.

Description

The CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS7:CLSA-2026:1792976962 advisory.

- In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg() syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with pkt_len = 0 but ath9k_hif_usb_rx_stream() uses __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb with uninitialized memory and ath9k_htc_rx_msg() is reading from uninitialized memory. Since bytes accessed by ath9k_htc_rx_msg() is not known until ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid pkt_len at if (pkt_len > 2 * MAX_RX_BUF_SIZE) { line in ath9k_hif_usb_rx_stream(). We have two choices. One is to workaround by adding __GFP_ZERO so that ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose the latter. Note that I'm not sure threshold condition is correct, for I can't find details on possible packet length used by this protocol. (CVE-2022-50709)

- In the Linux kernel, the following vulnerability has been resolved: configfs: fix possible memory leak in configfs_create_dir() kmemleak reported memory leaks in configfs_create_dir(): unreferenced object 0xffff888009f6af00 (size 192): comm modprobe, pid 3777, jiffies 4295537735 (age 233.784s) backtrace:
kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs/configfs/dir.c:1857) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... unreferenced object 0xffff888003ba7180 (size 96): comm modprobe, pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852) configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... This is because the refcount is not correct in configfs_make_dirent(). For normal stage, the refcount is changing as: configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2 ... configfs_unregister_subsystem() configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ...
*dentry_unlink_inode()* configfs_d_iput() # s_count = 0, release However, if we failed in configfs_create(): configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count = 2 ... configfs_create() # fail ->out_remove: configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1 return PTR_ERR(inode); There is no inode in the error path, so the configfs_d_iput() is lost and makes sd and fragment memory leaked. To fix this, when we failed in configfs_create(), manually call configfs_put(sd) to keep the refcount correct. (CVE-2022-50751)

- In the Linux kernel, the following vulnerability has been resolved: pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP An oops can be induced by running 'cat /proc/kcore > /dev/null' on devices using pstore with the ram backend because kmap_atomic() assumes lowmem pages are accessible with __va(). Unable to handle kernel paging request at virtual address ffffff807ff2b000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000 [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: dm_integrity CPU:
7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x110/0x260 lr : vread+0x194/0x294 sp :
ffffffc013ee39d0 x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000 x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000 x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21:
ffffffc0085a2000 x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60 x14: ffffffffad588000 x13: 0000000000000000 x12:
0000000000000001 x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 :
ffffffc013ee3a78 x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000 Call trace:
__memcpy+0x110/0x260 read_kcore+0x584/0x778 proc_reg_read+0xb4/0xe4 During early boot, memblock reserves the pages for the ramoops reserved memory node in DT that would otherwise be part of the direct lowmem mapping. Pstore's ram backend reuses those reserved pages to change the memory type (writeback or non- cached) by passing the pages to vmap() (see pfn_to_page() usage in persistent_ram_vmap() for more details) with specific flags. When read_kcore() starts iterating over the vmalloc region, it runs over the virtual address that vmap() returned for ramoops. In aligned_vread() the virtual address is passed to vmalloc_to_page() which returns the page struct for the reserved lowmem area. That lowmem page is passed to kmap_atomic(), which effectively calls page_to_virt() that assumes a lowmem page struct must be directly accessible with __va() and friends. These pages are mapped via vmap() though, and the lowmem mapping was never made, so accessing them via the lowmem virtual address oopses like above. Let's side- step this problem by passing VM_IOREMAP to vmap(). This will tell vread() to not include the ramoops region in the kcore. Instead the area will look like a bunch of zeros. The alternative is to teach kmap() about vmalloc areas that intersect with lowmem. Presumably such a change isn't a one-liner, and there isn't much interest in inspecting the ramoops region in kcore files anyway, so the most expedient route is taken for now. (CVE-2022-50849)

- In the Linux kernel, the following vulnerability has been resolved: hwrng: amd - Fix PCI device refcount leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the normal and error path. (CVE-2022-50868)

- In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. (CVE-2023-52515)

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

Solution

Update the affected packages based on the guidance in TuxCare advisory CENTOS7:CLSA-2026:1792976962.

Plugin Details

Severity: High

ID: 374124

File Name: tuxcare_centos_7_CLSA-2026-1792976962.nasl

Version: 1.1

Type: Local

Agent: unix

Family: CentOS Local Security Checks

Published: 10/30/2026

Updated: 10/30/2026

Supported Sensors: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus

Risk Information

VPR

Risk Factor: High

Score: 7.9

Percentile: 99.34

Vendor

Vendor Severity: Important

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5

Vector: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C

CVSS Score Source: CVE-2026-46294

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 6.8

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Required KB Items: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/OS/extended-third-party

Exploit Ease: No known exploits are available

Patch Publication Date: 10/26/2026

Vulnerability Publication Date: 7/21/2021

Reference Information

CVE: CVE-2022-50709, CVE-2022-50751, CVE-2022-50849, CVE-2022-50868, CVE-2023-52515, CVE-2023-53754, CVE-2023-53802, CVE-2023-53831, CVE-2023-54067, CVE-2023-54284, CVE-2024-47713, CVE-2024-50076, CVE-2024-50289, CVE-2026-45920, CVE-2026-46294, CVE-2026-53392, CVE-2026-63904, CVE-2026-63916, CVE-2026-63917, CVE-2026-63921, CVE-2026-63990, CVE-2026-64115, CVE-2026-64276, CVE-2026-64351, CVE-2026-64465, CVE-2026-68118, CVE-2026-68146, CVE-2026-68326, CVE-2026-68377, CVE-2026-68405, CVE-2026-68428, CVE-2026-68436, CVE-2026-72017, CVE-2026-72021, CVE-2026-72108, CVE-2026-72238, CVE-2026-72243, CVE-2026-72250, CVE-2026-72251, CVE-2026-72284, CVE-2026-72319, CVE-2026-72321, CVE-2026-72322, CVE-2026-72350, CVE-2026-72392, CVE-2026-72421, CVE-2026-74271, CVE-2026-74330, CVE-2026-74388, CVE-2026-74417, CVE-2026-74485, CVE-2026-74544, CVE-2026-80628, CVE-2026-80659, CVE-2026-80664, CVE-2026-80689, CVE-2026-80706, CVE-2026-80765, CVE-2026-80783, CVE-2026-80785, CVE-2026-80819, CVE-2026-80824, CVE-2026-80827, CVE-2026-80828, CVE-2026-80847, CVE-2026-80875, CVE-2026-80912, CVE-2026-80973, CVE-2026-80977, CVE-2026-89485, CVE-2026-89515, CVE-2026-89527, CVE-2026-89540, CVE-2026-89541, CVE-2026-89559, CVE-2026-89595, CVE-2026-89628, CVE-2026-89631, CVE-2026-89638, CVE-2026-89659, CVE-2026-89666, CVE-2026-89672, CVE-2026-89722, CVE-2026-89783, CVE-2026-89784, CVE-2026-89965, CVE-2026-90103, CVE-2026-90151, CVE-2026-90235, CVE-2026-90293, CVE-2026-90294, CVE-2026-90307, CVE-2026-90345, CVE-2026-90383, CVE-2026-92499, CVE-2026-93048, CVE-2026-93140, CVE-2026-93206, CVE-2026-93251, CVE-2026-93793, CVE-2026-97518, CVE-2026-97561, CVE-2026-97929, CVE-2026-97930, CVE-2026-97938, CVE-2026-98015, CVE-2026-98099, CVE-2026-98176, CVE-2026-98177, CVE-2026-98186, CVE-2026-98357, CVE-2026-98358, CVE-2026-98359, CVE-2026-98486, CVE-2026-98488, CVE-2026-98489, CVE-2026-98494, CVE-2026-98501

CLSA: 2026:1792976962

Detections

Analytics