In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue When value < time_unit, the parameter of ilog2() will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger shift-out-of-bounds: shift exponent 18446744073709551615 is too large for 32-bit type 'int' Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us

The CentOS Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS-STREAM8:CLSA-2026:1780132980 advisory.

  - kernel/module.c in the Linux kernel before 5.12.14 mishandles Signature Verification, aka     CID-0c18f29aae7c. Without CONFIG_MODULE_SIG, verification that a kernel module is signed, for loading via     init_module, does not occur for a module.sig_enforce=1 command-line argument. (CVE-2021-35039)

  - In drivers/char/virtio_console.c in the Linux kernel before 5.13.4, data corruption or loss can be     triggered by an untrusted device that supplies a buf->len value exceeding the buffer size. NOTE: the     vendor indicates that the cited data corruption is not a vulnerability in any existing use case; the     length validation was added solely for robustness in the face of anomalous host OS behavior     (CVE-2021-38160)

  - There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect     and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively)     remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within     proximity of the victim. We recommend upgrading past commit https://www.google.com/url     https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4     https://www.google.com/url (CVE-2022-42896)

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential double free in     create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable     ref_field, which is allocated in the previous function call to create_hist_field(). Function     init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when     the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling,     which frees the fields and the variable itself. This results in double free of the fields which are     already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are     freed in init_var_ref(). (CVE-2022-49410)

  - In the Linux kernel, the following vulnerability has been resolved: HID: elan: Fix potential double free     in elan_input_configured 'input' is a managed resource allocated with devm_input_allocate_device(), so     there is no need to call input_free_device() explicitly or there will be a double free. According to the     doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or
    * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails).
    (CVE-2022-49508)

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

The CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS7:CLSA-2026:1782148320 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: media: ngene: Fix out-of-bounds bug in     ngene_command_config_free_buf() Fix an 11-year old bug in ngene_command_config_free_buf() while addressing     the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning:
    '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject     'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25:
    warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced     subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the     original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue     FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because     memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is     FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also,     the name of the function ngene_command_config_free_buf() suggests that the actual intention is to     ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function     ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct     FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the     destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps     with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the     FORTIFY_SOURCE routines on memcpy(). (CVE-2021-47288)

  - In the Linux kernel, the following vulnerability has been resolved: nvme: fix a possible use-after-free in     controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl     readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.
    The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. ->     nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in     turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed,     submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In     order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER     submission. This addresses the above race in controller resets because the driver during teardown should:
    1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So     after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting     the AER. (CVE-2022-48790)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for     aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle     the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the     SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However,     if the I/O completion occurs later, the I/O completion still thinks that the sas_task is available. Fix     this by clearing the ccb->task if the TMF times out - the I/O completion handler does nothing if this     pointer is cleared. (CVE-2022-48791)

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used     dynamic event is removed After 65536 dynamic events have been added and removed, the type field of the     event then uses the first type number that is available (not currently used by other events). A type     number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to     logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced     and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be     created and destroyed), if another dynamic event is created that has the same number that new event's     logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash     the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2     $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will     remove the old event and create a new one (with the same format) and increase the type number to the next     available on until the type number reaches over 65535 which is the max number for the 16 bit type. After     it reaches that number, the logic to allocate a new number simply looks for the next available number.
    When an dynamic event is removed, that number is then available to be reused by the next dynamic event     created. That is, once the above reaches the max number, the number assigned to the event in that loop     will remain the same. Now that means deleting one dynamic event and created another will reuse the     previous events type number. This is where bad things can happen. After the above loop finishes, the     kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 >     kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and     create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' >     kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo:
    (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240)     arg1=     cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240)     arg1=     cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240)     arg1=     cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240)     arg1= ---truncated--- (CVE-2022-49006)

  - In the Linux kernel, the following vulnerability has been resolved: dm raid: fix accesses beyond end of     raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array     rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid     metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being     requested, that number can be different from the current number of members for existing raid sets as     defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed -     raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 ->     raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the     potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the     rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix     validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up     raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was     verified to pass all LVM2 RAID tests (with KASAN enabled). (CVE-2022-49674)

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

The CentOS Linux 8.5 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.5:CLSA-2026:1768775579 advisory.

  - An issue was discovered in slc_bump in drivers/net/can/slcan.c in the Linux kernel 3.16 through 5.6.2. It     allows attackers to read uninitialized can_frame data, potentially containing sensitive information from     kernel stack memory, if the configuration lacks CONFIG_INIT_STACK_ALL, aka CID-b9258a2cece4.
    (CVE-2020-11494)

  - An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx driver in     drivers/gpu/vmxgfx/vmxgfx_kms.c in GPU component in the Linux kernel with device file '/dev/dri/renderD128     (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing     a denial of service(DoS). (CVE-2022-36280)

  - In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix potential out of bounds     access with invalid rxstatus->rs_keyix The rxstatus->rs_keyix eventually gets passed to test_bit() so we     need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46     ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' (CVE-2022-49503)

  - In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix double     ata_host_put() in ata_tport_add() In the error path in ata_tport_add(), when calling put_device(),     ata_tport_release() is called, it will put the refcount of 'ap->host'. And then ata_host_put() is called     again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null.
    When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a     null-ptr-deref(), because all the ports all freed and null. Unable to handle kernel NULL pointer     dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G     E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc :
    ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Call trace: ata_host_stop+0x3c/0x84 [libata]     release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70     really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120
    __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240     driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Fix     this by removing redundant ata_host_put() in the error path. (CVE-2022-49826)

  - In the Linux kernel, the following vulnerability has been resolved: capabilities: fix undefined behavior     in bit shift for CAP_TO_MASK Shifting signed 32-bit value by 31 bits is undefined, so changing significant     bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in     security/commoncap.c:1252:2 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace:
    <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c cap_task_prctl+0x561/0x6f0 security_task_prctl+0x5a/0xb0
    __x64_sys_prctl+0x61/0x8f0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK>     (CVE-2022-49870)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential double free in     create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable     ref_field, which is allocated in the previous function call to create_hist_field(). Function     init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when     the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling,     which frees the fields and the variable itself. This results in double free of the fields which are     already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are     freed in init_var_ref(). (CVE-2022-49410)

  - In the Linux kernel, the following vulnerability has been resolved: net: mdio: fix undefined behavior in     bit shift for __mdiobus_register Shifting signed 32-bit value by 31 bits is undefined, so changing     significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in     drivers/net/phy/mdio_bus.c:586:27 left shift of 1 by 31 places cannot be represented in type 'int' Call     Trace: <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c __mdiobus_register+0x49d/0x4e0     fixed_mdio_bus_init+0xd8/0x12d do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422     kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30 </TASK> (CVE-2022-49907)

  - In the Linux kernel, the following vulnerability has been resolved: vt: Clear selection before changing     the font When changing the console font with ioctl(KDFONTOP) the new font size can be bigger than the     previous font. A previous selection may thus now be outside of the new screen size and thus trigger out-     of-bounds accesses to graphics memory if the selection is removed in vc_do_resize(). Prevent such out-of-     memory accesses by dropping the selection before the various con_font_set() console handlers are called.
    (CVE-2022-49948)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix double free on     tx path. We see kernel crashes and lockups and KASAN errors related to ax210 firmware crashes. One of the     KASAN dumps pointed at the tx path, and it appears there is indeed a way to double-free an skb. If     iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the method will be freed. But, in case where     we build TSO skb buffer, the skb may also be freed in error case. So, return 0 in that particular error     case and do cleanup manually. BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90 iwlwifi     0000:06:00.0: 0x00000000 | tsf hi Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650 CPU: 4     PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5 iwlwifi 0000:06:00.0: 0x00000000 | time gp1 Hardware     name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019 Call Trace: <TASK>     dump_stack_lvl+0x55/0x6d print_report.cold.12+0xf2/0x684 iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2 ?
    __list_del_entry_valid+0x12/0x90 kasan_report+0x8b/0x180 iwlwifi 0000:06:00.0: 0x00000001 | uCode revision     type ? __list_del_entry_valid+0x12/0x90 __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000048     | uCode version major tcp_update_skb_after_send+0x5d/0x170 __tcp_transmit_skb+0xb61/0x15c0 iwlwifi     0000:06:00.0: 0xDAA05125 | uCode version minor ? __tcp_select_window+0x490/0x490 iwlwifi 0000:06:00.0:
    0x00000420 | hw version ? trace_kmalloc_node+0x29/0xd0 ? __kmalloc_node_track_caller+0x12a/0x260 ?     memset+0x1f/0x40 ? __build_skb_around+0x125/0x150 ? __alloc_skb+0x1d4/0x220 ?     skb_zerocopy_clone+0x55/0x230 iwlwifi 0000:06:00.0: 0x00489002 | board version ? kmalloc_reserve+0x80/0x80     ? rcu_read_lock_bh_held+0x60/0xb0 tcp_write_xmit+0x3f1/0x24d0 iwlwifi 0000:06:00.0: 0x034E001C | hcmd ?
    __check_object_size+0x180/0x350 iwlwifi 0000:06:00.0: 0x24020000 | isr0 tcp_sendmsg_locked+0x8a9/0x1520     iwlwifi 0000:06:00.0: 0x01400000 | isr1 ? tcp_sendpage+0x50/0x50 iwlwifi 0000:06:00.0: 0x48F0000A | isr2 ?     lock_release+0xb9/0x400 ? tcp_sendmsg+0x14/0x40 iwlwifi 0000:06:00.0: 0x00C3080C | isr3 ?     lock_downgrade+0x390/0x390 ? do_raw_spin_lock+0x114/0x1d0 iwlwifi 0000:06:00.0: 0x00200000 | isr4 ?     rwlock_bug.part.2+0x50/0x50 iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id ? rwlock_bug.part.2+0x50/0x50 ?     lockdep_hardirqs_on_prepare+0xe/0x200 iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event ?
    __local_bh_enable_ip+0x87/0xe0 ? inet_send_prepare+0x220/0x220 iwlwifi 0000:06:00.0: 0x000000C4 |     l2p_control tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration
    __sys_sendto+0x19d/0x250 iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid ? __ia32_sys_getpeername+0x40/0x40     iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match ? rcu_read_lock_held_common+0x12/0x50 ?     rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_sched_held+0x5a/0xd0     ? rcu_read_lock_sched_held+0x5a/0xd0 ? lock_release+0xb9/0x400 ? lock_downgrade+0x390/0x390 ?     ktime_get+0x64/0x130 ? ktime_get+0x8d/0x130 ? rcu_read_lock_held_common+0x12/0x50 ?     rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_held_common+0x12/0x50 ?     rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_bh_held+0xb0/0xb0
    __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP:
    0033:0x7f1d126e4531 Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0     75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20     48 89 RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX:
    000000000000ffdc RCX: 00007f1d126e4531 RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014     RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000246 R ---truncated--- (CVE-2022-50248)

  - In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_usb_sdmmc: fix return value     check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that     allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added     device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the     error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called.
    (CVE-2022-50347)

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-992849 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue

    When value < time_unit, the parameter of ilog2() will be zero and     the return value is -1. u64(-1) is too large for shift exponent     and then will trigger shift-out-of-bounds:

    shift exponent 18446744073709551615 is too large for 32-bit type 'int'     Call Trace:
     rapl_compute_time_window_core      rapl_write_data_raw      set_time_window      store_constraint_time_window_us

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

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-992177 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue

    When value < time_unit, the parameter of ilog2() will be zero and     the return value is -1. u64(-1) is too large for shift exponent     and then will trigger shift-out-of-bounds:

    shift exponent 18446744073709551615 is too large for 32-bit type 'int'     Call Trace:
     rapl_compute_time_window_core      rapl_write_data_raw      set_time_window      store_constraint_time_window_us

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

Note that Nessus has not tested for this issue 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.

  - powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue When value < time_unit, the parameter of ilog2()     will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger     shift-out-of-bounds: shift exponent 18446744073709551615 is too large for 32-bit type 'int' Call Trace:
    rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us     (CVE-2022-50366)

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
362073	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1780132980)	Nessus	CentOS Local Security Checks	Local	high
353232	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1782148320)	Nessus	CentOS Local Security Checks	Local	high
353189	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1768775579)	Nessus	CentOS Local Security Checks	Local	high
353159	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1777616064)	Nessus	Alma Linux Local Security Checks	Local	high
302981	EulerOS Virtualization 2.13.1 : kernel (EulerOS-SA-2026-1637)	Nessus	Huawei Local Security Checks	Local	high
302971	EulerOS Virtualization 2.13.0 : kernel (EulerOS-SA-2026-1629)	Nessus	Huawei Local Security Checks	Local	high
297598	EulerOS 2.0 SP13 : kernel (EulerOS-SA-2026-1212)	Nessus	Huawei Local Security Checks	Local	high
297592	EulerOS 2.0 SP13 : kernel (EulerOS-SA-2026-1224)	Nessus	Huawei Local Security Checks	Local	high
280879	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2025-992849)	Nessus	Unity Linux Local Security Checks	Local	high
280543	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2025-992177)	Nessus	Unity Linux Local Security Checks	Local	high
265657	Linux Distros Unpatched Vulnerability : CVE-2022-50366	Nessus	Misc.	Local	high
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2022-50366

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high

high