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

    - sunrpc: handle SVC_GARBAGE during svc auth processing as auth error (Jeff Layton)  [Orabug: 38137447]     {CVE-2025-38089}
    - Add Zen34 clients (Borislav Petkov (AMD))  [Orabug: 38172252]  {CVE-2024-36350} {CVE-2024-36357}
    - x86/process: Move the buffer clearing before MONITOR (Kim Phillips)  [Orabug: 38172252]     {CVE-2024-36350} {CVE-2024-36357}
    - Add normal counters (Borislav Petkov (AMD))  [Orabug: 38172252]  {CVE-2024-36350} {CVE-2024-36357}
    - KVM: SVM: Advertize TSA CPUID bits to guests (Borislav Petkov (AMD))  [Orabug: 38172252]     {CVE-2024-36350} {CVE-2024-36357}
    - x86/bugs: Add a Transient Scheduler Attacks mitigation (Borislav Petkov (AMD))  [Orabug: 38172252]     {CVE-2024-36350} {CVE-2024-36357}

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 version of Tencent Linux installed on the remote TencentOS Server 4 host is prior to tested version. It is, therefore, affected by multiple vulnerabilities as referenced in the TSSA-2025:0349 advisory.

    Package updates are available for TencentOS Server 4 that fix the following vulnerabilities:

    CVE-2024-50262:
    In the Linux kernel, the following vulnerability has been resolved:

    firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()

    Clang static checker(scan-build) throws below warning     |  drivers/firmware/arm_scmi/driver.c:line 2915, column 2     |        Attempt to free released memory.

    When devm_add_action_or_reset() fails, scmi_debugfs_common_cleanup()     will run twice which causes double free of 'dbg->name'.

    Remove the redundant scmi_debugfs_common_cleanup() to fix this problem.

    CVE-2024-49969:
    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Fix overloading of MEM_UNINIT's meaning

    Lonial reported an issue in the BPF verifier where check_mem_size_reg()     has the following code:

      if (!tnum_is_const(reg->var_off))           /* For unprivileged variable accesses, disable raw
           * mode so that the program is required to
           * initialize all the memory that the helper could
           * just partially fill up.
           */            meta = NULL;

    This means that writes are not checked when the register containing the     size of the passed buffer has not a fixed size. Through this bug, a BPF     program can write to a map which is marked as read-only, for example,     .rodata global maps.

    The problem is that MEM_UNINIT's initial meaning that the passed buffer     to the BPF helper does not need to be initialized which was added back     in commit 435faee1aae9 (bpf, verifier: add ARG_PTR_TO_RAW_STACK type)     got overloaded over time with the passed buffer is being written to.

    The problem however is that checks such as the above which were added later     via 06c1c049721a (bpf: allow helpers access to variable memory) set meta     to NULL in order force the user to always initialize the passed buffer to     the helper. Due to the current double meaning of MEM_UNINIT, this bypasses     verifier write checks to the memory (not boundary checks though) and only     assumes the latter memory is read instead.

    Fix this by reverting MEM_UNINIT back to its original meaning, and having     MEM_WRITE as an annotation to BPF helpers in order to then trigger the     BPF verifier checks for writing to memory.

    Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO}     we can access fn->arg_type[arg - 1] since it must contain a preceding     ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed     altogether since we do check both BPF_READ and BPF_WRITE. Same for the     equivalent check_kfunc_mem_size_reg().

    CVE-2024-50063:
    In the Linux kernel, the following vulnerability has been resolved:

    RDMA/bnxt_re: Add a check for memory allocation

    __alloc_pbl() can return error when memory allocation fails.
    Driver is not checking the status on one of the instances.

    CVE-2024-53082:
    In the Linux kernel, the following vulnerability has been resolved:

    wifi: iwlegacy: Clear stale interrupts before resuming device

    iwl4965 fails upon resume from hibernation on my laptop. The reason     seems to be a stale interrupt which isn't being cleared out before     interrupts are enabled. We end up with a race beween the resume     trying to bring things back up, and the restart work (queued form     the interrupt handler) trying to bring things down. Eventually     the whole thing blows up.

    Fix the problem by clearing out any stale interrupts before     interrupts get enabled during resume.

    Here's a debug log of the indicent:
    [   12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000     [   12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000     [   12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.
    [   12.042653] iwl4965 0000:10:00.0: On demand firmware reload     [   12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000,     flags 0x00000282     [   12.052207] ieee80211 phy0: il4965_mac_start enter     [   12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff     [   12.052244] ieee80211 phy0: il4965_set_hw_ready hardware  ready     [   12.052324] ieee80211 phy0: il_apm_init Init card's basic functions     [   12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S     [   12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm     [   12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm     [   12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK     [   12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations     [   12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up     [   12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.
    [   12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down     [   12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout     [   12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort     [   12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver     [   12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared     [   12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state     [   12.058827] ieee80211 phy0: _il_apm_stop_master stop master     [   12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.
    [   12.058869] ieee80211 phy0: Hardware restart was requested     [   16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.
    [   16.132303] ------------[ cut here ]------------     [   16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or     a hardware issue.
    [   16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0     [mac80211]     [   16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter     iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl     btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog     pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256     firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class     iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core     rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight     e1000e agpgart evdev     [   16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143     [   16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010     [   16.132463] Workqueue: async async_run_entry_fn     [   16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211]     [   16.132501] Code: da 02 00 0
    ---truncated---

    CVE-2024-50209:
    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Fix out-of-bounds write in trie_get_next_key()

    trie_get_next_key() allocates a node stack with size trie->max_prefixlen,     while it writes (trie->max_prefixlen + 1) nodes to the stack when it has     full paths from the root to leaves. For example, consider a trie with     max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...
    0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with     .prefixlen = 8 make 9 nodes be written on the node stack with size 8.

    CVE-2022-30594:
    In the Linux kernel, the following vulnerability has been resolved:

    virtio_net: Add hash_key_length check

    Add hash_key_length check in virtnet_probe() to avoid possible out of     bound errors when setting/reading the hash key.

    CVE-2024-50159:
    It was discovered that the eBPF implementation in the Linux kernel did not properly track bounds     information for 32 bit registers when performing div and mod operations. A local attacker could use this     to possibly execute arbitrary code.

    CVE-2024-50164:
    The Linux kernel before 5.17.2 mishandles seccomp permissions. The PTRACE_SEIZE code path allows attackers     to bypass intended restrictions on setting the PT_SUSPEND_SECCOMP flag.

    CVE-2021-3600:
    In the Linux kernel, the following vulnerability has been resolved:

    ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()

    The documentation for device_get_named_child_node() mentions this     important point:

        The caller is responsible for calling fwnode_handle_put() on the     returned fwnode pointer.
    

    Add fwnode_handle_put() to avoid a leaked reference.

    CVE-2025-21655:
    In the Linux kernel, the following vulnerability has been resolved:

    drm/amd/display: Fix index out of bounds in DCN30 color transformation

    This commit addresses a potential index out of bounds issue in the     `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color     management module. The issue could occur when the index 'i' exceeds the     number of transfer function points (TRANSFER_FUNC_POINTS).

    The fix adds a check to ensure 'i' is within bounds before accessing the     transfer function points. If 'i' is out of bounds, the function returns     false to indicate an error.

    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180     cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max     drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181     cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max     drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182     cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

    CVE-2024-50234:
    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Prevent tail call between progs attached to different hooks

    bpf progs can be attached to kernel functions, and the attached functions     can take different parameters or return different return values. If     prog attached to one kernel function tail calls prog attached to another     kernel function, the ctx access or return value verification could be     bypassed.

    For example, if prog1 is attached to func1 which takes only 1 parameter     and prog2 is attached to func2 which takes two parameters. Since verifier     assumes the bpf ctx passed to prog2 is constructed based on func2's     prototype, verifier allows prog2 to access the second parameter from     the bpf ctx passed to it. The problem is that verifier does not prevent     prog1 from passing its bpf ctx to prog2 via tail call. In this case,     the bpf ctx passed to prog2 is constructed from func1 instead of func2,     that is, the assumption for ctx access verification is bypassed.

    Another example, if BPF LSM prog1 is attached to hook file_alloc_security,     and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier     knows the return value rules for these two hooks, e.g. it is legal for     bpf_lsm_audit_rule_known to return positive number 1, and it is illegal     for file_alloc_security to return positive number. So verifier allows     prog2 to return positive number 1, but does not allow prog1 to return     positive number. The problem is that verifier does not prevent prog1     from calling prog2 via tail call. In this case, prog2's return value 1     will be used as the return value for prog1's hook file_alloc_security.
    That is, the return value rule is bypassed.

    This patch adds restriction for tail call to prevent such bypasses.

    CVE-2024-36955:
    In the Linux kernel, the following vulnerability has been resolved:

    io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period

    io_eventfd_do_signal() is invoked from an RCU callback, but when     dropping the reference to the io_ev_fd, it calls io_eventfd_free()     directly if the refcount drops to zero. This isn't correct, as any     potential freeing of the io_ev_fd should be deferred another RCU grace     period.

    Just call io_eventfd_put() rather than open-code the dec-and-test and     free, which will correctly defer it another RCU grace period.

Tenable has extracted the preceding description block directly from the Tencent 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.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
252244	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2025-20530)	Nessus	Oracle Linux Local Security Checks	2025/8/19	2026/2/9	medium
276015	TencentOS Server 4: kernel (TSSA-2025:0349)	Nessus	Tencent Local Security Checks	2025/11/20	2025/11/20	high

检测

插件搜索

medium

high