In the Linux kernel, the following vulnerability has been resolved: refscale: Fix uninitalized use of wait_queue_head_t Running the refscale test occasionally crashes the kernel with the following error: [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 8569.952900] #PF: supervisor read access in kernel mode [ 8569.952902] #PF: error_code(0x0000) - not-present page [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0 [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021 [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 : [ 8569.952940] Call Trace: [ 8569.952941] <TASK> [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale] [ 8569.952959] kthread+0x10e/0x130 [ 8569.952966] ret_from_fork+0x1f/0x30 [ 8569.952973] </TASK> The likely cause is that init_waitqueue_head() is called after the call to the torture_create_kthread() function that creates the ref_scale_reader kthread. Although this init_waitqueue_head() call will very likely complete before this kthread is created and starts running, it is possible that the calling kthread will be delayed between the calls to torture_create_kthread() and init_waitqueue_head(). In this case, the new kthread will use the waitqueue head before it is properly initialized, which is not good for the kernel's health and well-being. The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here The offset of flags from list_head entry in wait_queue_entry is -0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task structure is zero initialized, the instruction will try to access address 0xffffffffffffffe8, which is exactly the fault address listed above. This commit therefore invokes init_waitqueue_head() before creating the kthread.

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

  - In the Linux kernel, the following vulnerability has been resolved: hwmon: (w83792d) Fix NULL pointer     dereference by removing unnecessary structure field If driver read val value sufficient for (val & 0x08)     && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7)) from device then Null pointer dereference     occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not     serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The     patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification     project (linuxtesting.org). [groeck: Dropped unnecessary continuation lines, fixed multipline alignment]     (CVE-2021-47385)

  - In the Linux kernel, the following vulnerability has been resolved: hwmon: (w83791d) Fix NULL pointer     dereference by removing unnecessary structure field If driver read val value sufficient for (val & 0x08)     && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7)) from device then Null pointer dereference     occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not     serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The     patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification     project (linuxtesting.org). [groeck: Dropped unnecessary continuation lines, fixed multi-line alignment]     (CVE-2021-47386)

  - In the Linux kernel, the following vulnerability has been resolved: mm/uffd: fix pte marker when fork()     without fork event Patch series mm: Fixes on pte markers. Patch 1 resolves the syzkiller report from     Pengfei. Patch 2 further harden pte markers when used with the recent swapin error markers. The major case     is we should persist a swapin error marker after fork(), so child shouldn't read a corrupted page. This     patch (of 2): When fork(), dst_vma is not guaranteed to have VM_UFFD_WP even if src may have it and has     pte marker installed. The warning is improper along with the comment. The right thing is to inherit the     pte marker when needed, or keep the dst pte empty. A vague guess is this happened by an accident when     there's the prior patch to introduce src/dst vma into this helper during the uffd-wp feature got developed     and I probably messed up in the rebase, since if we replace dst_vma with src_vma the warning & comment it     all makes sense too. Hugetlb did exactly the right here (copy_hugetlb_page_range()). Fix the general path.
    Reproducer: https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c     Bugzilla report: https://bugzilla.kernel.org/show_bug.cgi?id=216808 (CVE-2022-49744)

  - In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix memory leak in     vkms_init() A memory leak was reported after the vkms module install failed. unreferenced object     0xffff88810bc28520 (size 16): comm modprobe, pid 9662, jiffies 4298009455 (age 42.590s) hex dump (first     16 bytes): 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............ backtrace:
    [<00000000e7561ff8>] kmalloc_trace+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>]     do_one_initcall+0xd0/0x4f0 [<000000001505ee87>] do_init_module+0x1a4/0x680 [<00000000958079ad>]     load_module+0x6249/0x7110 [<00000000117e4696>] __do_sys_finit_module+0x140/0x200 [<00000000f74b12d2>]     do_syscall_64+0x35/0x80 [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that     the vkms_init() returns without checking the return value of vkms_create(), and if the vkms_create()     failed, the config allocated at the beginning of vkms_init() is leaked. vkms_init() config = kmalloc(...)     # config allocated ... return vkms_create() # vkms_create failed and config is leaked Fix this problem by     checking return value of vkms_create() and free the config if error happened. (CVE-2022-50269)

  - In the Linux kernel, the following vulnerability has been resolved: net: hns: fix possible memory leak in     hnae_ae_register() Inject fault while probing module, if device_register() fails, but the refcount of     kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling     put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object     0xffff00c01aba2100 (size 128): comm systemd-udevd, pid 1259, jiffies 4294903284 (age 294.152s) hex dump     (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00     00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0     [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>]
    __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>]     kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>]     dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>]     hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]     (CVE-2022-50352)

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

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - refscale: Fix uninitalized use of wait_queue_head_t Running the refscale test occasionally crashes the     kernel with the following error: [ 8569.952896] BUG: unable to handle page fault for address:
    ffffffffffffffe8 [ 8569.952900] #PF: supervisor read access in kernel mode [ 8569.952902] #PF:
    error_code(0x0000) - not-present page [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0 [     8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI [ 8569.952916] Hardware name: Dell Inc. PowerEdge     R750/0WMWCR, BIOS 1.2.4 05/28/2021 [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 : [     8569.952940] Call Trace: [ 8569.952941] <TASK> [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale] [     8569.952959] kthread+0x10e/0x130 [ 8569.952966] ret_from_fork+0x1f/0x30 [ 8569.952973] </TASK> The likely     cause is that init_waitqueue_head() is called after the call to the torture_create_kthread() function that     creates the ref_scale_reader kthread. Although this init_waitqueue_head() call will very likely complete     before this kthread is created and starts running, it is possible that the calling kthread will be delayed     between the calls to torture_create_kthread() and init_waitqueue_head(). In this case, the new kthread     will use the waitqueue head before it is properly initialized, which is not good for the kernel's health     and well-being. The above crash happened here: static inline void __add_wait_queue(...) { : if     (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here The offset of flags from list_head entry in     wait_queue_entry is -0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task structure is     zero initialized, the instruction will try to access address 0xffffffffffffffe8, which is exactly the     fault address listed above. This commit therefore invokes init_waitqueue_head() before creating the     kthread. (CVE-2023-54316)

Note that Nessus relies on the presence of the package as reported by the vendor.

An update of the linux package has been released.

ID	Name	Product	Family	Type	Severity
361044	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1783355084)	Nessus	Alma Linux Local Security Checks	Local	medium
297194	SUSE SLED15 / SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:0315-1)	Nessus	SuSE Local Security Checks	Local	high
296680	SUSE SLES15 / openSUSE 15 : Security update for the Linux Kernel (SUSE-SU-2026:0293-1)	Nessus	SuSE Local Security Checks	Local	high
296676	SUSE SLES15: kernel-azure / kernel-azure-devel / kernel-devel-azure / etc (SUSE-SU-2026:0281-1)	Nessus	SuSE Local Security Checks	Local	high
296481	SUSE SLES15 Security Update : kernel (SUSE-SU-2026:0278-1)	Nessus	SuSE Local Security Checks	Local	high
281525	Linux Distros Unpatched Vulnerability : CVE-2023-54316	Nessus	Misc.	Local	medium
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2023-54316

medium

Tenable Plugins

medium

high

high

high

high

medium

high