kernel: Secure Boot does not automatically enable kernel lockdown

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

  - kernel: Secure Boot does not automatically enable kernel lockdown (CVE-2025-1272)

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

The remote Oracle Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2025-6966 advisory.

    - net: stmmac: dwmac-tegra: Read iommu stream id from device tree (Izabela Bakollari) [RHEL-75649]     {CVE-2025-21663}
    - net: stmmac: Fix zero-division error when disabling tc cbs (Izabela Bakollari) [RHEL-63931]     {CVE-2024-49977}
    - scsi: qla2xxx: Fix use after free on unload (Ewan D. Milne) [RHEL-75828] {CVE-2024-56623}

Tenable has extracted the preceding description block directly from the Oracle Linux security advisory.

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

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-573.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Fix slab-use-after-free read     in sg_release() Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN: BUG: KASAN: slab-     use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838
    __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407     In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the     open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its     cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via     sg_remove_sfp_usercontext(), which ultimately frees sfp. After kref_put(), sg_release() continues to     unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-     use-after-free error. Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock     mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. -     Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without     impacting the mutex handling in sg_release(). The fix has been tested and validated by syzbot. This patch     closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup     and mutex operations, eliminating the risk of use-after-free errors in sg_release(). (CVE-2024-56631)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: sanitize CAN ID checks in     isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached     with a compliant CAN ID address configuration. The provided address information consisted of CAN ID     0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the     SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - In the Linux kernel, the following vulnerability has been resolved: can: bcm: Fix UAF in bcm_proc_show()     BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80 Read of size 8 at addr ffff888155846230 by     task cat/7862 CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230 Hardware name:
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK>     dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80     seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0     ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task     7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0     bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0
    __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task     7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40
    ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0     rcu_core+0x809/0x1bd0 bcm_op is freed before procfs entry be removed in bcm_release(), this lead to     bcm_proc_show() may read the freed bcm_op. (CVE-2023-52922)

  - In the Linux kernel, the following vulnerability has been resolved: x86/xen: don't do PV iret hypercall     through hypercall page Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly     code the required sequence in xen-asm.S. This is done in preparation of no longer using hypercall page at     all, as it has shown to cause problems with speculation mitigations. This is part of XSA-466 /     CVE-2024-53241. (CVE-2024-53241)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix for a     potential deadlock This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ----
    ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex);
    lock(&shost->scan_mutex); Fix this by temporarily releasing the reset_mutex. (CVE-2024-57807)

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

The remote Fedora 41 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2025-cca2fcc70c advisory.

    The 6.12.15 stable kernel update contains a number of important fixes across the tree.

    ----

    The 6.12.14 stable kernel update contains a number of important fixes across the tree.

Tenable has extracted the preceding description block directly from the Fedora security advisory.

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

The remote Fedora 40 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2025-b268fceaec advisory.

    The 6.12.15 stable kernel update contains a number of important fixes across the tree.

    ----

    The 6.12.14 stable kernel update contains a number of important fixes across the tree.

Tenable has extracted the preceding description block directly from the Fedora security advisory.

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

ID	Name	Product	Family	Severity
282947	MiracleLinux 9 : kernel-5.14.0-570.12.1.el9_6 (AXSA:2025-10392:38)	Nessus	Miracle Linux Local Security Checks	critical
247810	Linux Distros Unpatched Vulnerability : CVE-2025-1272	Nessus	Misc.	high
237324	RHEL 9 : kernel (RHSA-2025:6966)	Nessus	Red Hat Local Security Checks	critical
237030	Oracle Linux 9 : kernel (ELSA-2025-6966)	Nessus	Oracle Linux Local Security Checks	critical
233298	CentOS 9 : kernel-5.14.0-573.el9	Nessus	CentOS Local Security Checks	high
216512	Fedora 41 : kernel (2025-cca2fcc70c)	Nessus	Fedora Local Security Checks	critical
216506	Fedora 40 : kernel (2025-b268fceaec)	Nessus	Fedora Local Security Checks	critical

Detections

Analytics

CVE-2025-1272

high

Tenable Plugins

critical

high

critical

critical

high

critical

critical