The remote Ubuntu 24.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6952-1 advisory.

    Benedict Schlter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde discovered that an untrusted     hypervisor could inject malicious #VC interrupts and compromise the security guarantees of AMD SEV-SNP.
    This flaw is known as WeSee. A local attacker in control of the hypervisor could use this to expose     sensitive information or possibly execute arbitrary code in the trusted execution environment.
    (CVE-2024-25742)

    Several security issues were discovered in the Linux kernel. An attacker could possibly use these to     compromise the system. This update corrects flaws in the following subsystems:

    - ARM32 architecture;

    - ARM64 architecture;

    - M68K architecture;

    - OpenRISC architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - x86 architecture;

    - Block layer subsystem;

    - Accessibility subsystem;

    - Bluetooth drivers;

    - Clock framework and drivers;

    - CPU frequency scaling framework;

    - Hardware crypto device drivers;

    - DMA engine subsystem;

    - DPLL subsystem;

    - FireWire subsystem;

    - EFI core;

    - Qualcomm firmware drivers;

    - GPIO subsystem;

    - GPU drivers;

    - HID subsystem;

    - Microsoft Hyper-V drivers;

    - I2C subsystem;

    - InfiniBand drivers;

    - IOMMU subsystem;

    - IRQ chip drivers;

    - Macintosh device drivers;

    - Multiple devices driver;

    - Media drivers;

    - EEPROM drivers;

    - MMC subsystem;

    - Network drivers;

    - STMicroelectronics network drivers;

    - Device tree and open firmware driver;

    - HiSilicon SoC PMU drivers;

    - PHY drivers;

    - Pin controllers subsystem;

    - Remote Processor subsystem;

    - S/390 drivers;

    - SCSI drivers;

    - SPI subsystem;

    - Media staging drivers;

    - Thermal drivers;

    - TTY drivers;

    - Userspace I/O drivers;

    - USB subsystem;

    - DesignWare USB3 driver;

    - ACRN Hypervisor Service Module driver;

    - Virtio drivers;

    - 9P distributed file system;

    - BTRFS file system;

    - eCrypt file system;

    - EROFS file system;

    - File systems infrastructure;

    - GFS2 file system;

    - JFFS2 file system;

    - Network file systems library;

    - Network file system client;

    - Network file system server daemon;

    - NILFS2 file system;

    - Proc file system;

    - SMB network file system;

    - Tracing file system;

    - Mellanox drivers;

    - Memory management;

    - Socket messages infrastructure;

    - Slab allocator;

    - Tracing infrastructure;

    - User-space API (UAPI);

    - Core kernel;

    - BPF subsystem;

    - DMA mapping infrastructure;

    - RCU subsystem;

    - Dynamic debug library;

    - KUnit library;

    - Maple Tree data structure library;

    - Heterogeneous memory management;

    - Amateur Radio drivers;

    - Bluetooth subsystem;

    - Ethernet bridge;

    - Networking core;

    - IPv4 networking;

    - IPv6 networking;

    - Multipath TCP;

    - Netfilter;

    - NET/ROM layer;

    - NFC subsystem;

    - NSH protocol;

    - Open vSwitch;

    - Phonet protocol;

    - SMC sockets;

    - TIPC protocol;

    - Unix domain sockets;

    - Wireless networking;

    - Key management;

    - ALSA framework;

    - HD-audio driver;

    - Kirkwood ASoC drivers;

    - MediaTek ASoC drivers; (CVE-2024-38601, CVE-2024-36935, CVE-2024-35991, CVE-2024-36032, CVE-2024-35988,     CVE-2024-36886, CVE-2024-36913, CVE-2024-36928, CVE-2024-38553, CVE-2024-36927, CVE-2024-38615,     CVE-2024-36958, CVE-2024-36977, CVE-2024-36889, CVE-2024-38554, CVE-2024-38590, CVE-2024-42134,     CVE-2024-35857, CVE-2024-35850, CVE-2024-35986, CVE-2024-36921, CVE-2024-38569, CVE-2024-36966,     CVE-2024-38542, CVE-2024-38585, CVE-2024-36884, CVE-2024-36006, CVE-2024-38577, CVE-2024-36016,     CVE-2024-38584, CVE-2024-36887, CVE-2024-38598, CVE-2024-35994, CVE-2024-38603, CVE-2024-35998,     CVE-2024-27401, CVE-2024-35852, CVE-2024-36944, CVE-2024-38572, CVE-2024-36917, CVE-2024-36943,     CVE-2024-36009, CVE-2024-38587, CVE-2024-35949, CVE-2024-36945, CVE-2024-36004, CVE-2024-36919,     CVE-2024-27398, CVE-2024-38582, CVE-2024-35847, CVE-2024-38580, CVE-2024-38602, CVE-2024-36916,     CVE-2024-36903, CVE-2024-38555, CVE-2024-36952, CVE-2024-38589, CVE-2024-27394, CVE-2024-36933,     CVE-2024-36975, CVE-2024-38591, CVE-2024-38612, CVE-2024-36939, CVE-2024-35983, CVE-2024-38607,     CVE-2024-36929, CVE-2024-35849, CVE-2024-36941, CVE-2024-35858, CVE-2024-38599, CVE-2024-35996,     CVE-2024-36031, CVE-2024-36931, CVE-2024-35990, CVE-2024-35851, CVE-2024-38556, CVE-2024-36000,     CVE-2024-36910, CVE-2024-38573, CVE-2024-36906, CVE-2024-36951, CVE-2024-38604, CVE-2024-38613,     CVE-2024-38547, CVE-2024-36014, CVE-2024-36949, CVE-2024-36033, CVE-2024-38597, CVE-2024-36880,     CVE-2024-38594, CVE-2024-36894, CVE-2024-38546, CVE-2024-36947, CVE-2024-38541, CVE-2024-35989,     CVE-2024-27399, CVE-2024-38550, CVE-2024-36922, CVE-2024-36008, CVE-2024-38540, CVE-2024-36924,     CVE-2024-36892, CVE-2024-38549, CVE-2024-36882, CVE-2024-36908, CVE-2024-38566, CVE-2024-36005,     CVE-2024-38583, CVE-2024-36968, CVE-2024-36017, CVE-2024-38565, CVE-2024-36881, CVE-2024-38611,     CVE-2024-36897, CVE-2024-38560, CVE-2024-36923, CVE-2024-38575, CVE-2024-36899, CVE-2024-38570,     CVE-2024-36898, CVE-2024-36896, CVE-2024-38559, CVE-2024-38588, CVE-2024-38606, CVE-2024-38551,     CVE-2024-36891, CVE-2024-38567, CVE-2024-36895, CVE-2024-35993, CVE-2024-38552, CVE-2024-36925,     CVE-2024-36964, CVE-2024-36888, CVE-2024-36956, CVE-2024-36946, CVE-2024-38600, CVE-2024-35997,     CVE-2024-36912, CVE-2024-35984, CVE-2024-35848, CVE-2024-38545, CVE-2024-38563, CVE-2024-36918,     CVE-2024-36001, CVE-2024-36957, CVE-2024-38576, CVE-2024-36030, CVE-2024-38574, CVE-2024-36963,     CVE-2024-36890, CVE-2024-36960, CVE-2024-36901, CVE-2024-38614, CVE-2024-35859, CVE-2024-38593,     CVE-2024-36904, CVE-2024-36012, CVE-2024-38578, CVE-2024-36011, CVE-2024-36930, CVE-2024-36938,     CVE-2024-36893, CVE-2024-35987, CVE-2024-36905, CVE-2024-35853, CVE-2024-36003, CVE-2024-38562,     CVE-2024-38617, CVE-2024-35855, CVE-2024-36965, CVE-2024-38596, CVE-2024-38558, CVE-2024-38568,     CVE-2024-36955, CVE-2024-36029, CVE-2024-36967, CVE-2024-36940, CVE-2024-38595, CVE-2024-36028,     CVE-2024-38610, CVE-2024-36911, CVE-2024-35999, CVE-2024-35854, CVE-2024-38571, CVE-2024-38548,     CVE-2024-36948, CVE-2024-36002, CVE-2024-36961, CVE-2024-36900, CVE-2024-36932, CVE-2024-36902,     CVE-2024-35992, CVE-2024-36914, CVE-2024-38592, CVE-2024-38616, CVE-2024-27400, CVE-2024-36937,     CVE-2024-36920, CVE-2024-38586, CVE-2024-36909, CVE-2024-35846, CVE-2024-39482, CVE-2024-38579,     CVE-2024-38539, CVE-2024-27395, CVE-2024-36962, CVE-2024-36013, CVE-2024-27396, CVE-2024-38557,     CVE-2024-36953, CVE-2024-41011, CVE-2023-52882, CVE-2024-36969, CVE-2024-36007, CVE-2024-35856,     CVE-2024-38605, CVE-2024-36915, CVE-2024-36979, CVE-2024-36954, CVE-2024-38538, CVE-2024-36950,     CVE-2024-36926, CVE-2024-38544, CVE-2024-36959, CVE-2024-38561, CVE-2024-36883, CVE-2024-36936,     CVE-2024-38564, CVE-2024-38543, CVE-2024-36934, CVE-2024-35947, CVE-2024-38620)

Tenable has extracted the preceding description block directly from the Ubuntu 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:0437 advisory.

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

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

    drm/amd/display: Assign linear_pitch_alignment even for VM

    [Description]     Assign linear_pitch_alignment so we don't cause a divide by 0     error in VM environments

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

    drm/amd/display: Ensure array index tg_inst won't be -1

    [WHY & HOW]     tg_inst will be a negative if timing_generator_count equals 0, which     should be checked before used.

    This fixes 2 OVERRUN issues reported by Coverity.

    CVE-2024-24861:
    A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000     xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to     malfunction or denial of service issue.






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

    scsi: qedf: Ensure the copied buf is NUL terminated

    Currently, we allocate a count-sized kernel buffer and copy count from     userspace to that buffer. Later, we use kstrtouint on this buffer but we     don't ensure that the string is terminated inside the buffer, this can     lead to OOB read when using kstrtouint. Fix this issue by using     memdup_user_nul instead of memdup_user.

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

    drm/i915/gt: Reset queue_priority_hint on parking

    Originally, with strict in order execution, we could complete execution     only when the queue was empty. Preempt-to-busy allows replacement of an     active request that may complete before the preemption is processed by     HW. If that happens, the request is retired from the queue, but the     queue_priority_hint remains set, preventing direct submission until     after the next CS interrupt is processed.

    This preempt-to-busy race can be triggered by the heartbeat, which will     also act as the power-management barrier and upon completion allow us to     idle the HW. We may process the completion of the heartbeat, and begin     parking the engine before the CS event that restores the     queue_priority_hint, causing us to fail the assertion that it is MIN.

    <3>[  166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U     >> 1)) - 1))     <0>[  166.210781] Dumping ftrace buffer:
    <0>[  166.210795] ---------------------------------     ...
    <0>[  167.302811] drm_fdin-1097      2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote {     ccid:20 1217:2 prio 0 }     <0>[  167.302861] drm_fdin-1097      2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0:
    preempting last=1217:2, prio=0, hint=2147483646     <0>[  167.302928] drm_fdin-1097      2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0:
    fence 1217:2, current 0     <0>[  167.302992] drm_fdin-1097      2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence     3:4660, current 4659     <0>[  167.303044] drm_fdin-1097      2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0:
    context:3 schedule-in, ccid:40     <0>[  167.303095] drm_fdin-1097      2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40     3:4660* prio 2147483646 }     <0>[  167.303159] kworker/-89       11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0:
    fence c90:2, current 2     <0>[  167.303208] kworker/-89       11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0:
    context:c90 unpin     <0>[  167.303272] kworker/-89       11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0:
    fence 1217:2, current 2     <0>[  167.303321] kworker/-89       11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0:
    context:1217 unpin     <0>[  167.303384] kworker/-89       11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0:
    fence 3:4660, current 4660     <0>[  167.303434] kworker/-89       11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0:
    context:1216 retire runtime: { total:56028ns, avg:56028ns }     <0>[  167.303484] kworker/-89       11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked     <0>[  167.303534]   <idle>-0         5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0:
    semaphore yield: 00000040     <0>[  167.303583] kworker/-89       11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0:
    context:1217 retire runtime: { total:325575ns, avg:0ns }     <0>[  167.303756] kworker/-89       11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0:
    context:c90 retire runtime: { total:0ns, avg:0ns }     <0>[  167.303806] kworker/-89       11..... 165742017us : __engine_park: __engine_park:283     GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))     <0>[  167.303811] ---------------------------------     <4>[  167.304722] ------------[ cut here ]------------     <2>[  167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!     <4>[  167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI     <4>[  167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G        W     6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1     <4>[  167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP,     BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022     <4>[  167.304738] Workqueue: i915-unordered retire_work_handler [i915]     <4>[  16
    ---truncated---

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

    scsi: core: Fix unremoved procfs host directory regression

    Commit fc663711b944 (scsi: core: Remove the /proc/scsi/${proc_name}     directory earlier) fixed a bug related to modules loading/unloading, by     adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led     to a potential duplicate call to the hostdir_rm() routine, since it's also     called from scsi_host_dev_release(). That triggered a regression report,     which was then fixed by commit be03df3d4bfe (scsi: core: Fix a procfs host     directory removal regression). The fix just dropped the hostdir_rm() call     from dev_release().

    But it happens that this proc directory is created on scsi_host_alloc(),     and that function pairs with scsi_host_dev_release(), while     scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the     reason for removing the proc directory on dev_release() was meant to cover     cases in which a SCSI host structure was allocated, but the call to     scsi_add_host() didn't happen. And that pattern happens to exist in some     error paths, for example.

    Syzkaller causes that by using USB raw gadget device, error'ing on     usb-storage driver, at usb_stor_probe2(). By checking that path, we can see     that the BadDevice label leads to a scsi_host_put() after a SCSI host     allocation, but there's no call to scsi_add_host() in such path. That leads     to messages like this in dmesg (and a leak of the SCSI host proc     structure):

    usb-storage 4-1:87.51: USB Mass Storage device detected     proc_dir_entry 'scsi/usb-storage' already registered     WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376

    The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),     but guard that with the state check for SHOST_CREATED; there is even a     comment in scsi_host_dev_release() detailing that: such conditional is     meant for cases where the SCSI host was allocated but there was no calls to     {add,remove}_host(), like the usb-storage case.

    This is what we propose here and with that, the error path of usb-storage     does not trigger the warning anymore.

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

    USB: core: Fix deadlock in usb_deauthorize_interface()

    Among the attribute file callback routines in     drivers/usb/core/sysfs.c, the interface_authorized_store() function is     the only one which acquires a device lock on an ancestor device: It     calls usb_deauthorize_interface(), which locks the interface's parent     USB device.

    The will lead to deadlock if another process already owns that lock     and tries to remove the interface, whether through a configuration     change or because the device has been disconnected.  As part of the     removal procedure, device_del() waits for all ongoing sysfs attribute     callbacks to complete.  But usb_deauthorize_interface() can't complete     until the device lock has been released, and the lock won't be     released until the removal has finished.

    The mechanism provided by sysfs to prevent this kind of deadlock is     to use the sysfs_break_active_protection() function, which tells sysfs     not to wait for the attribute callback.

    Reported-and-tested by: Yue Sun <samsun1006219@gmail.com>     Reported by: xingwei lee <xrivendell7@gmail.com>

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

    scsi: qla2xxx: Fix command flush on cable pull

    System crash due to command failed to flush back to SCSI layer.

     BUG: unable to handle kernel NULL pointer dereference at 0000000000000000      PGD 0 P4D 0      Oops: 0000 [#1] SMP NOPTI      CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G           OE    --------- -  -     4.18.0-372.9.1.el8.x86_64 #1      Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021      Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]      RIP: 0010:__wake_up_common+0x4c/0x190      Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18     48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75      RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086      RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000      RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320      RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8      R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20      R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000      FS:  0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033      CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400      PKRU: 55555554      Call Trace:
    __wake_up_common_lock+0x7c/0xc0     qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]      qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000     from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0      ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]      qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST -     portid=010200.
    ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]      qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles     1      ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]      qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000     from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0     ? __switch_to+0x10c/0x450      ? process_one_work+0x1a7/0x360      qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST -     portid=010201.
    ? worker_thread+0x1ce/0x390     ? create_worker+0x1a0/0x1a0      qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles     70     ? kthread+0x10a/0x120      qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000     21320102adf7eeb8     ? set_kthread_struct+0x40/0x40      qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed.
    ? ret_from_fork+0x1f/0x40      qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout

    The system was under memory stress where driver was not able to allocate an     SRB to carry out error recovery of cable pull.  The failure to flush causes     upper layer to start modifying scsi_cmnd.  When the system frees up some     memory, the subsequent cable pull trigger another command flush. At this     point the driver access a null pointer when attempting to DMA unmap the     SGL.

    Add a check to make sure commands are flush back on session tear down to     prevent the null pointer access.

    CVE-2023-52853:
    In the Linux kernel, the following vulnerability has been resolved:

    hid: cp2112: Fix duplicate workqueue initialization

    Previously the cp2112 driver called INIT_DELAYED_WORK within     cp2112_gpio_irq_startup, resulting in duplicate initilizations of the     workqueue on subsequent IRQ startups following an initial request. This     resulted in a warning in set_work_data in workqueue.c, as well as a rare     NULL dereference within process_one_work in workqueue.c.

    Initialize the workqueue within _probe instead.

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

    sctp: fix memory leak in sctp_stream_outq_migrate()

    When sctp_stream_outq_migrate() is called to release stream out resources,     the memory pointed to by prio_head in stream out is not released.

    The memory leak information is as follows:
     unreferenced object 0xffff88801fe79f80 (size 64):
     comm sctp_repo, pid 7957, jiffies 4294951704 (age 36.480s)      hex dump (first 32 bytes):
       80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff  ................
       90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff  ................
     backtrace:
       [<ffffffff81b215c6>] kmalloc_trace+0x26/0x60        [<ffffffff88ae517c>] sctp_sched_prio_set+0x4cc/0x770        [<ffffffff88ad64f2>] sctp_stream_init_ext+0xd2/0x1b0        [<ffffffff88aa2604>] sctp_sendmsg_to_asoc+0x1614/0x1a30        [<ffffffff88ab7ff1>] sctp_sendmsg+0xda1/0x1ef0        [<ffffffff87f765ed>] inet_sendmsg+0x9d/0xe0        [<ffffffff8754b5b3>] sock_sendmsg+0xd3/0x120        [<ffffffff8755446a>] __sys_sendto+0x23a/0x340        [<ffffffff87554651>] __x64_sys_sendto+0xe1/0x1b0        [<ffffffff89978b49>] do_syscall_64+0x39/0xb0        [<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

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	Name	Product	Family	Published	Updated	Severity
205289	Ubuntu 24.04 LTS : Linux kernel vulnerabilities (USN-6952-1)	Nessus	Ubuntu Local Security Checks	8/9/2024	1/6/2026	high
276192	TencentOS Server 4: kernel (TSSA-2025:0437)	Nessus	Tencent Local Security Checks	11/20/2025	11/20/2025	high

Detections

Analytics

Plugins Search

high

high