In the Linux kernel, the following vulnerability has been resolved: powerpc/xive/spapr: correct bitmap allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency.

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:1027-1 advisory.

    The SUSE Linux Enterprise 15 SP4 kernel was updated to receive various security bugfixes.


    The following security bugs were fixed:

    - CVE-2024-2201: Fixed information leak in x86/BHI (bsc#1217339).
    - CVE-2024-41092: drm/i915/gt: Fix potential UAF by revoke of fence registers (bsc#1228483).
    - CVE-2024-42098: crypto: ecdh - explicitly zeroize private_key (bsc#1228779).
    - CVE-2024-42229: crypto: aead,cipher - zeroize key buffer after use (bsc#1228708).
    - CVE-2024-57996: net_sched: sch_sfq: do not allow 1 packet limit (bsc#1239076).
    - CVE-2024-58014: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() (bsc#1239109).
    - CVE-2025-21718: net: rose: fix timer races against user threads (bsc#1239073).
    - CVE-2025-21780: drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table() (bsc#1239115).


Tenable has extracted the preceding description block directly from the SUSE 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-572.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds     write to cacheinfo array The loop that detects/populates cache information already has a bounds check on     the array size but does not account for cache levels with separate data/instructions cache. Fix this by     incrementing the index for any populated leaf (instead of any populated level). (CVE-2025-21785)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/xive/spapr: correct bitmap     allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-     of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1     CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace:
    [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0]     [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354     [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0]
    _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260     [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20]     pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac     [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90]     [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54]     ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0
    __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84     start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at     c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes     inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical     page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558     pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200     c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff     0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address:
    c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc     fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^     c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc     fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should     pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object     can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and     initialize the irq bitmap, paired with bitmap_free() for consistency. (CVE-2022-49623)

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory     as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU.
    XPU may sometime falsely detect clean cache eviction as write into the write protected region leading to     secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right     now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation     tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know     anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to     MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by     updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. (CVE-2024-46689)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to     reschedule during overflow flush In terms of normal application usage, this list will always be empty. And     if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents     syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take     quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary.
    There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and     reacquire the locks at the end of the loop. (CVE-2024-50060)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check     for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super     block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will     grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to     finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently     attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes     to complete, but the previous writes cannot complete, as the task that is supposed to complete them is     blocked waiting on starting a new write. This results in the following stuck trace showing that dependency     with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call     trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8
    __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110
    __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238     do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO:
    task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with     the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364     ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0     percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18
    __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238     do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this     by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem     if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will     have io_uring core issue a blocking attempt of the write. That will in turn also get completions run,     ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something     that can be triggered by a regular user. (CVE-2024-53052)

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.

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/xive/spapr: correct bitmap     allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-     of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1     CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace:
    [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0]     [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354     [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0]
    _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260     [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20]     pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac     [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90]     [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54]     ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0
    __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84     start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at     c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes     inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical     page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558     pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200     c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff     0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address:
    c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc     fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^     c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc     fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should     pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object     can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and     initialize the irq bitmap, paired with bitmap_free() for consistency. (CVE-2022-49623)

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

ID	Name	Product	Family	Severity
233410	SUSE SLES15 Security Update : kernel (SUSE-SU-2025:1027-1)	Nessus	SuSE Local Security Checks	high
232849	CentOS 9 : kernel-5.14.0-572.el9	Nessus	CentOS Local Security Checks	high
227053	Linux Distros Unpatched Vulnerability : CVE-2022-49623	Nessus	Misc.	high

Detections

Analytics

CVE-2022-49623

high

Tenable Plugins

high

high

high