The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1783362244 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: extcon: Modify extcon device to be     created after driver data is set Currently, someone can invoke the sysfs such as state_show()     intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is     Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace.
    Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from     [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show)     [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>]     (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read)     from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>]     (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return)     (CVE-2022-49308)

  - In the Linux kernel, the following vulnerability has been resolved: tick/nohz: unexport __init-annotated     tick_nohz_full_setup() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is     freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a     freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade.
    Commit 28438794aba4 (modpost: fix section mismatch check for exported init/exit sections) fixed it so     modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost:
    vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable
    __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol     tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of     tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called     from the built-in code in kernel/sched/isolation.c. (CVE-2022-49675)

  - In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: fix NULL pointer     deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of     ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops     as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to     '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center     (linuxtesting.org) with the SVACE static analysis tool. (CVE-2022-49731)

  - In the Linux kernel, the following vulnerability has been resolved: bridge: switchdev: Fix memory leaks     when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via     switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the     'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the     bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously     mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the     'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the     existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were     offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are     already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change     the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite     these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the     VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via     switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm ip, pid 446855, jiffies     4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00     ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:
    [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920     [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0     [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00     [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710     [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0     [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0     [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90     [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49812)

  - In the Linux kernel, the following vulnerability has been resolved: capabilities: fix potential memleak on     error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to     complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed     to call handler->get(...), there will be a memleak in below logic: |-- ret =     (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value,     error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |--
    *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after     vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks] (CVE-2022-49890)

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

The AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1781344094 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: i2c: designware: use casting of u64 in     clock multiplication to avoid overflow In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have     overflow by depending on the values of the given parameters including the ic_clk. For example in our use     case where ic_clk is larger than one million, multiplication of ic_clk * 4700 will result in 32 bit     overflow. Add cast of u64 to the calculation to avoid multiplication overflow, and use the corresponding     define for divide. (CVE-2022-49749)

  - In the Linux kernel, the following vulnerability has been resolved: kernel/irq/irqdomain.c: fix memory     leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it,     otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove()     instead which handles all of the logic at once. (CVE-2023-52936)

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Fix null pointer dereference     in tracing_err_log_open() Fix an issue in function 'tracing_err_log_open'. The function doesn't call     'seq_open' if the file is opened only with write permissions, which results in 'file->private_data' being     left as null. If we then use 'lseek' on that opened file, 'seq_lseek' dereferences 'file->private_data' in     'mutex_lock(&m->lock)', resulting in a kernel panic. Writing to this node requires root privileges,     therefore this bug has very little security impact. Tracefs node: /sys/kernel/tracing/error_log Example     Kernel panic: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call     trace: mutex_lock+0x30/0x110 seq_lseek+0x34/0xb8 __arm64_sys_lseek+0x6c/0xb8 invoke_syscall+0x58/0x13c     el0_svc_common+0xc4/0x10c do_el0_svc+0x24/0x98 el0_svc+0x24/0x88 el0t_64_sync_handler+0x84/0xe4     el0t_64_sync+0x1b4/0x1b8 Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02) ---[ end trace     561d1b49c12cf8a5 ]--- Kernel panic - not syncing: Oops: Fatal exception (CVE-2023-53167)

  - In the Linux kernel, the following vulnerability has been resolved: irqchip: Fix refcount leak in     platform_irqchip_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should     use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
    (CVE-2023-53610)

  - In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix kernel NULL     pointer dereference in hv_uio_rescind For primary VM Bus channels, primary_channel pointer is always NULL.
    This pointer is valid only for the secondary channels. Also, rescind callback is meant for primary     channels only. Fix NULL pointer dereference by retrieving the device_obj from the parent for the primary     channel. (CVE-2024-46739)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
360687	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1783362244)	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/19	high
360739	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1781344094)	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/21	high
297598	EulerOS 2.0 SP13 : kernel (EulerOS-SA-2026-1212)	Nessus	Huawei Local Security Checks	2026/2/2	2026/9/18	high

检测

插件搜索

high

high

high