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

  - In the Linux kernel, the following vulnerability has been resolved: mptcp: fix 'scheduling while atomic'     in mptcp_pm_nl_append_new_local_addr If multiple connection requests attempt to create an implicit mptcp     endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none     found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id. In this case, the     concurrent new_local_addr calls may delete the address entry created by the previous caller. These deletes     use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called.
    During packet recv, the caller may be in a rcu read critical section and have preemption disabled. An     example stack: BUG: scheduling while atomic: swapper/2/0/0x00000302 Call Trace: <IRQ> dump_stack_lvl     (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug     (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33     kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207     kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84     kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160)     wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116     kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311     kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr     (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id     (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req     (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305)     tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651)     tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv     (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))     ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver     (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)     ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv     (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core     (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685     net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449     include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
    __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs     (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)     irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ>     This problem seems particularly prevalent if the user advertises an endpoint that has a different external     vs internal address. In the case where the external address is advertised and multiple connections already     exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the     first local_addr_list entries which have the internal address instead. Fix by skipping the replacement of     an existing implicit local address if called via mptcp_pm_nl_get_local_id. (CVE-2025-21938)

  - In the Linux kernel, the following vulnerability has been resolved: mm/debug_vm_pgtable: clear page table     entries at destroy_args() The mm/debug_vm_pagetable test allocates manually page table entries for the     tests it runs, using also its manually allocated mm_struct. That in itself is ok, but when it exits, at     destroy_args() it fails to clear those entries with the *_clear functions. The problem is that leaves     stale entries. If another process allocates an mm_struct with a pgd at the same address, it may end up     running into the stale entry. This is happening in practice on a debug kernel with     CONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extra debugging I added (it prints a     warning trace if pgtables_bytes goes negative, in addition to the warning at check_mm() function): [     2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000 [ 2.539366] kmem_cache     info [ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508 [ 2.539447]     debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e (...) [ 2.552800] WARNING: CPU: 5 PID: 116     at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0 [ 2.552816] Modules linked in: [ 2.552843] CPU: 5     UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY [     2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062)     hv:phyp pSeries [ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90 [ 2.552885]     REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug) [ 2.552899] MSR:
    800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 0000000a [ 2.552954] CFAR:
    c0000000008f03f0 IRQMASK: 0 [ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00     0000000000000001 [ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff [     2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000 [ 2.552954] GPR12:
    00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb [ 2.552954] GPR16: 0000000000000000     0000000000000008 000000000000000a 60000000000000e0 [ 2.552954] GPR20: 4080000000000000 c0000000113af038     00007fffcf130000 0000700000000000 [ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000     0000000000000001 [ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760 [     2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0 [ 2.553185] LR [c0000000007eef30]     free_pud_range+0x8b0/0x8d0 [ 2.553199] Call Trace: [ 2.553207] [c0000000622e7650] [c0000000007eef30]     free_pud_range+0x8b0/0x8d0 (unreliable) [ 2.553229] [c0000000622e7750] [c0000000007f40b4]     free_pgd_range+0x284/0x3b0 [ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570 [     2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650 [ 2.553292] [c0000000622e7a30]     [c0000000001b95b8] __mmput+0x98/0x290 [ 2.558344] [c0000000622e7a80] [c0000000001d1018]     exit_mm+0x118/0x1b0 [ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870 [ 2.558376]     [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150 [ 2.558391] [c0000000622e7bb0]     [c0000000001d1db8] sys_exit_group+0x48/0x50 [ 2.558407] [c0000000622e7be0] [c00000000003d810]     system_call_exception+0x1e0/0x4c0 [ 2.558423] [c0000000622e7e50] [c00000000000d05c]     system_call_vectored_common+0x15c/0x2ec (...) [ 2.558892] ---[ end trace 0000000000000000 ]--- [ 2.559022]     BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1 [ 2.559037] BUG: non-zero     pgtables_bytes on freeing mm: -6144 Here the modprobe process ended up with an allocated mm_struct from     the mm_struct slab that was used before by the debug_vm_pgtable test. That is not a problem, since the     mm_stru ---truncated--- (CVE-2025-39776)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header     before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset     types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an     Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between     `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet     device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing     `eth_hdr(skb)`. (CVE-2026-53131)

  - In the Linux kernel, the following vulnerability has been resolved: kernfs: Relax constraint in draining     guard The active reference lifecycle provides the break/unbreak mechanism but the active reference is not     truly active after unbreak -- callers don't use it afterwards but it's important for proper pairing of     kn->active counting. Assuming this mechanism is in place, the WARN check in     kernfs_should_drain_open_files() is too sensitive -- it may transiently catch those (rightful) callers     between kernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen Ridong:
    kernfs_remove_by_name_ns kernfs_get_active // active=1 __kernfs_remove // active=0x80000002 kernfs_drain     ... wait_event //waiting (active == 0x80000001) kernfs_break_active_protection // active = 0x80000001 //     continue kernfs_unbreak_active_protection // active = 0x80000002 ... kernfs_should_drain_open_files //     warning occurs kernfs_put_active To avoid the false positives (mind panic_on_warn) remove the check     altogether. (This is meant as quick fix, I think active reference break/unbreak may be simplified with     larger rework.) (CVE-2025-38282)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of     MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and     filtering out EINPROGRESS notifications. (CVE-2026-43493)

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

偵測

搜尋 Plugin

high