Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1791800936)

high Nessus Plugin ID 364682

Synopsis

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

Description

The Rocky Linux 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: kunit: Fix potential null dereference in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

- In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written back to target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing contents of FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d (CVE-2024-57878)

- 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: devlink: fix xa_alloc_cyclic() error handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
(CVE-2025-22017)

- In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

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 ALMALINUX9.6:CLSA-2026:1791800936.

Plugin Details

Severity: High

ID: 364682

File Name: tuxcare_rocky_linux_9.6_CLSA-2026-1791800936.nasl

Version: 1.1

Type: Local

Family: Rocky Linux Local Security Checks

Published: 10/12/2026

Updated: 10/12/2026

Supported Sensors: Nessus Agent, Continuous Assessment, Nessus

Risk Information

VPR

Risk Factor: Critical

Score: 9.3

Percentile: 99.82

Vendor

Vendor Severity: Critical

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5.6

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

CVSS Score Source: CVE-2026-64381

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7.2

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:F/RL:O/RC:C

Vulnerability Information

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

Exploit Available: true

Exploit Ease: Exploits are available

Patch Publication Date: 10/12/2026

Vulnerability Publication Date: 9/6/2023

CISA Known Exploited Vulnerability Due Dates: 9/21/2026

Reference Information

CVE: CVE-2023-53698, CVE-2024-56710, CVE-2024-56773, CVE-2024-57878, CVE-2024-57994, CVE-2025-21632, CVE-2025-21880, CVE-2025-21889, CVE-2025-21895, CVE-2025-21913, CVE-2025-21938, CVE-2025-22005, CVE-2025-22017, CVE-2025-37791, CVE-2025-37869, CVE-2025-37891, CVE-2025-37936, CVE-2025-38170, CVE-2025-38282, CVE-2025-38427, CVE-2025-38552, CVE-2025-39776, CVE-2025-39865, CVE-2025-39926, CVE-2025-39980, CVE-2025-40042, CVE-2025-40044, CVE-2025-40078, CVE-2025-40103, CVE-2025-40153, CVE-2025-40178, CVE-2025-40254, CVE-2025-40280, CVE-2025-40324, CVE-2025-68185, CVE-2025-68241, CVE-2025-68264, CVE-2025-68336, CVE-2026-23272, CVE-2026-23278, CVE-2026-23457, CVE-2026-23458, CVE-2026-31394, CVE-2026-31447, CVE-2026-31516, CVE-2026-31525, CVE-2026-31566, CVE-2026-31593, CVE-2026-31638, CVE-2026-31639, CVE-2026-31665, CVE-2026-31678, CVE-2026-31679, CVE-2026-31708, CVE-2026-31773, CVE-2026-43028, CVE-2026-43030, CVE-2026-43037, CVE-2026-43171, CVE-2026-43279, CVE-2026-43296, CVE-2026-43452, CVE-2026-43493, CVE-2026-45835, CVE-2026-45843, CVE-2026-45870, CVE-2026-45878, CVE-2026-45933, CVE-2026-46050, CVE-2026-46071, CVE-2026-46078, CVE-2026-46131, CVE-2026-46173, CVE-2026-46178, CVE-2026-46196, CVE-2026-46199, CVE-2026-46201, CVE-2026-46230, CVE-2026-46252, CVE-2026-52921, CVE-2026-52954, CVE-2026-52974, CVE-2026-52986, CVE-2026-52994, CVE-2026-52999, CVE-2026-53014, CVE-2026-53032, CVE-2026-53048, CVE-2026-53060, CVE-2026-53076, CVE-2026-53085, CVE-2026-53126, CVE-2026-53131, CVE-2026-53143, CVE-2026-53193, CVE-2026-53208, CVE-2026-53252, CVE-2026-53266, CVE-2026-53270, CVE-2026-53350, CVE-2026-53353, CVE-2026-53365, CVE-2026-63884, CVE-2026-63971, CVE-2026-64018, CVE-2026-64034, CVE-2026-64287, CVE-2026-64294, CVE-2026-64303, CVE-2026-64304, CVE-2026-64305, CVE-2026-64319, CVE-2026-64320, CVE-2026-64322, CVE-2026-64323, CVE-2026-64329, CVE-2026-64330, CVE-2026-64340, CVE-2026-64341, CVE-2026-64343, CVE-2026-64344, CVE-2026-64348, CVE-2026-64352, CVE-2026-64371, CVE-2026-64375, CVE-2026-64379, CVE-2026-64380, CVE-2026-64381, CVE-2026-64382, CVE-2026-64383, CVE-2026-64384, CVE-2026-64385, CVE-2026-64386, CVE-2026-64387, CVE-2026-64422, CVE-2026-64423, CVE-2026-64438, CVE-2026-64448, CVE-2026-64563, CVE-2026-64597, CVE-2026-68085, CVE-2026-68131, CVE-2026-68216, CVE-2026-68238, CVE-2026-68254, CVE-2026-68289, CVE-2026-72069, CVE-2026-72072, CVE-2026-72098, CVE-2026-72125, CVE-2026-72126, CVE-2026-72389, CVE-2026-72438, CVE-2026-74499, CVE-2026-74503, CVE-2026-74556, CVE-2026-74580, CVE-2026-74582, CVE-2026-74587, CVE-2026-74588, CVE-2026-74589, CVE-2026-74597, CVE-2026-74604, CVE-2026-74608, CVE-2026-74609, CVE-2026-74621, CVE-2026-74630, CVE-2026-74641, CVE-2026-74642, CVE-2026-74656, CVE-2026-74667, CVE-2026-74669, CVE-2026-74682, CVE-2026-74704, CVE-2026-74705, CVE-2026-74710, CVE-2026-74720, CVE-2026-74725, CVE-2026-74730, CVE-2026-74744, CVE-2026-74746, CVE-2026-74752, CVE-2026-80529, CVE-2026-80558, CVE-2026-80576, CVE-2026-81000, CVE-2026-89525, CVE-2026-89534, CVE-2026-89555, CVE-2026-89682

CLSA: 2026:1791800936

Detections

Analytics