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

    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:

    - ARM64 architecture;

    - PowerPC architecture;

    - Block layer subsystem;

    - Drivers core;

    - Network block device driver;

    - Character device driver;

    - GPU drivers;

    - HID subsystem;

    - InfiniBand drivers;

    - Media drivers;

    - Network drivers;

    - PPS (Pulse Per Second) driver;

    - PTP clock framework;

    - RapidIO drivers;

    - Real Time Clock drivers;

    - SCSI subsystem;

    - SLIMbus drivers;

    - QCOM SoC drivers;

    - Trusted Execution Environment drivers;

    - USB DSL drivers;

    - USB Device Class drivers;

    - USB core drivers;

    - USB Gadget drivers;

    - USB Host Controller drivers;

    - Renesas USBHS Controller drivers;

    - File systems infrastructure;

    - BTRFS file system;

    - NILFS2 file system;

    - UBI file system;

    - KVM subsystem;

    - L3 Master device support module;

    - Process Accounting mechanism;

    - printk logging mechanism;

    - Scheduler infrastructure;

    - Tracing infrastructure;

    - Memory management;

    - 802.1Q VLAN protocol;

    - B.A.T.M.A.N. meshing protocol;

    - Bluetooth subsystem;

    - Networking core;

    - IPv4 networking;

    - IPv6 networking;

    - Logical Link layer;

    - NFC subsystem;

    - Open vSwitch;

    - Rose network layer;

    - Network traffic control;

    - Wireless networking;

    - Tomoyo security module; (CVE-2025-21866, CVE-2025-21846, CVE-2025-21971, CVE-2025-21909, CVE-2024-58083,     CVE-2025-21811, CVE-2025-21776, CVE-2024-58051, CVE-2025-21917, CVE-2025-21935, CVE-2025-21785,     CVE-2021-47191, CVE-2025-21765, CVE-2025-21704, CVE-2025-21647, CVE-2024-58069, CVE-2025-21877,     CVE-2025-21948, CVE-2024-58007, CVE-2024-58001, CVE-2025-21871, CVE-2024-58055, CVE-2025-21848,     CVE-2025-21925, CVE-2024-58058, CVE-2025-21814, CVE-2025-21905, CVE-2025-21898, CVE-2025-21926,     CVE-2025-21760, CVE-2024-57973, CVE-2025-21806, CVE-2024-58071, CVE-2025-21761, CVE-2025-21762,     CVE-2024-57986, CVE-2025-21708, CVE-2025-21744, CVE-2024-26996, CVE-2024-50055, CVE-2024-58020,     CVE-2025-21858, CVE-2025-21715, CVE-2025-21904, CVE-2025-21920, CVE-2024-56599, CVE-2025-21781,     CVE-2025-21764, CVE-2025-21865, CVE-2025-21772, CVE-2024-58072, CVE-2025-21928, CVE-2025-21859,     CVE-2025-21721, CVE-2025-21719, CVE-2025-21914, CVE-2025-21753, CVE-2024-58009, CVE-2024-57981,     CVE-2024-58063, CVE-2024-58052, CVE-2025-21722, CVE-2024-57977, CVE-2025-21736, CVE-2025-21922,     CVE-2024-26982, CVE-2025-21718, CVE-2025-21916, CVE-2025-21749, CVE-2025-21787, CVE-2024-58085,     CVE-2024-58010, CVE-2024-57979, CVE-2024-57980, CVE-2025-21782, CVE-2025-21791, CVE-2025-21728,     CVE-2023-52741, CVE-2025-21934, CVE-2024-58002, CVE-2025-21735, CVE-2025-21910, CVE-2025-21823,     CVE-2024-58090, CVE-2025-21862, CVE-2025-21731, CVE-2025-21835, CVE-2024-58017, CVE-2024-58014,     CVE-2025-21763)

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 remote Debian 11 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4178 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4178-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     May 25, 2025                                  https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux     Version        : 5.10.237-1     CVE ID         : CVE-2021-47247 CVE-2021-47489 CVE-2022-48893 CVE-2022-49046                      CVE-2022-49190 CVE-2022-49219 CVE-2022-49309 CVE-2022-49546                      CVE-2022-49728 CVE-2023-52572 CVE-2023-52621 CVE-2023-52752                      CVE-2023-52757 CVE-2023-53034 CVE-2024-26686 CVE-2024-26928                      CVE-2024-26982 CVE-2024-35867 CVE-2024-35943 CVE-2024-36908                      CVE-2024-38611 CVE-2024-39494 CVE-2024-41073 CVE-2024-42322                      CVE-2024-44938 CVE-2024-46753 CVE-2024-46812 CVE-2024-46816                      CVE-2024-46821 CVE-2024-47726 CVE-2024-47730 CVE-2024-49960                      CVE-2024-50047 CVE-2024-50154 CVE-2024-50280 CVE-2024-53144                      CVE-2024-54458 CVE-2024-56599 CVE-2024-56608 CVE-2024-56658                      CVE-2024-56664 CVE-2024-57834 CVE-2024-57973 CVE-2024-57977                      CVE-2024-57979 CVE-2024-57980 CVE-2024-57981 CVE-2024-57986                      CVE-2024-58001 CVE-2024-58002 CVE-2024-58005 CVE-2024-58007                      CVE-2024-58010 CVE-2024-58014 CVE-2024-58016 CVE-2024-58017                      CVE-2024-58020 CVE-2024-58051 CVE-2024-58052 CVE-2024-58055                      CVE-2024-58058 CVE-2024-58063 CVE-2024-58069 CVE-2024-58071                      CVE-2024-58072 CVE-2024-58083 CVE-2024-58085 CVE-2024-58090                      CVE-2025-21647 CVE-2025-21700 CVE-2025-21702 CVE-2025-21704                      CVE-2025-21708 CVE-2025-21711 CVE-2025-21715 CVE-2025-21718                      CVE-2025-21719 CVE-2025-21721 CVE-2025-21722 CVE-2025-21726                      CVE-2025-21727 CVE-2025-21728 CVE-2025-21731 CVE-2025-21735                      CVE-2025-21736 CVE-2025-21744 CVE-2025-21745 CVE-2025-21749                      CVE-2025-21753 CVE-2025-21756 CVE-2025-21760 CVE-2025-21761                      CVE-2025-21762 CVE-2025-21763 CVE-2025-21764 CVE-2025-21765                      CVE-2025-21767 CVE-2025-21772 CVE-2025-21776 CVE-2025-21779                      CVE-2025-21781 CVE-2025-21782 CVE-2025-21785 CVE-2025-21787                      CVE-2025-21791 CVE-2025-21795 CVE-2025-21796 CVE-2025-21799                      CVE-2025-21802 CVE-2025-21804 CVE-2025-21806 CVE-2025-21811                      CVE-2025-21814 CVE-2025-21823 CVE-2025-21826 CVE-2025-21835                      CVE-2025-21844 CVE-2025-21846 CVE-2025-21848 CVE-2025-21853                      CVE-2025-21858 CVE-2025-21859 CVE-2025-21862 CVE-2025-21871                      CVE-2025-21872 CVE-2025-21875 CVE-2025-21877 CVE-2025-21878                      CVE-2025-21898 CVE-2025-21904 CVE-2025-21905 CVE-2025-21909                      CVE-2025-21910 CVE-2025-21914 CVE-2025-21916 CVE-2025-21917                      CVE-2025-21920 CVE-2025-21922 CVE-2025-21925 CVE-2025-21926                      CVE-2025-21928 CVE-2025-21934 CVE-2025-21935 CVE-2025-21941                      CVE-2025-21943 CVE-2025-21948 CVE-2025-21956 CVE-2025-21957                      CVE-2025-21959 CVE-2025-21968 CVE-2025-21971 CVE-2025-21975                      CVE-2025-21981 CVE-2025-21991 CVE-2025-21992 CVE-2025-21993                      CVE-2025-21996 CVE-2025-21999 CVE-2025-22004 CVE-2025-22005                      CVE-2025-22007 CVE-2025-22008 CVE-2025-22010 CVE-2025-22014                      CVE-2025-22018 CVE-2025-22020 CVE-2025-22021 CVE-2025-22025                      CVE-2025-22027 CVE-2025-22035 CVE-2025-22044 CVE-2025-22045                      CVE-2025-22054 CVE-2025-22055 CVE-2025-22056 CVE-2025-22063                      CVE-2025-22075 CVE-2025-22079 CVE-2025-22086 CVE-2025-23136                      CVE-2025-23138 CVE-2025-23140 CVE-2025-23142 CVE-2025-23144                      CVE-2025-23145 CVE-2025-23146 CVE-2025-23147 CVE-2025-23148                      CVE-2025-23150 CVE-2025-23156 CVE-2025-23157 CVE-2025-23158                      CVE-2025-23159 CVE-2025-23163 CVE-2025-37738 CVE-2025-37739                      CVE-2025-37740 CVE-2025-37741 CVE-2025-37749 CVE-2025-37756                      CVE-2025-37757 CVE-2025-37765 CVE-2025-37766 CVE-2025-37768                      CVE-2025-37770 CVE-2025-37773 CVE-2025-37780 CVE-2025-37781                      CVE-2025-37782 CVE-2025-37785 CVE-2025-37788 CVE-2025-37789                      CVE-2025-37792 CVE-2025-37794 CVE-2025-37796 CVE-2025-37797                      CVE-2025-37803 CVE-2025-37808 CVE-2025-37810 CVE-2025-37812                      CVE-2025-37817 CVE-2025-37823 CVE-2025-37824 CVE-2025-37829                      CVE-2025-37836 CVE-2025-37838 CVE-2025-37839 CVE-2025-37840                      CVE-2025-37841 CVE-2025-37844 CVE-2025-37850 CVE-2025-37851                      CVE-2025-37857 CVE-2025-37858 CVE-2025-37859 CVE-2025-37862                      CVE-2025-37867 CVE-2025-37871 CVE-2025-37881 CVE-2025-37885                      CVE-2025-38637 CVE-2025-39728 CVE-2025-39735

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For Debian 11 bullseye, these problems have been fixed in version     5.10.237-1.  This additionally includes many more bug fixes from     stable updates 5.10.235-5.10.237.

    We recommend that you upgrade your linux packages.

    For the detailed security status of linux please refer to     its security tracker page at:
    https://security-tracker.debian.org/tracker/linux

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

Tenable has extracted the preceding description block directly from the Debian 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 NewStart CGSL host, running version MAIN 7.02, has kernel packages installed that are affected by multiple vulnerabilities:

  - In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect     labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects     to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets     are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to     write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack     in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule     'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a     program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener     at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data     in both directions. * Collect network traffic of this connection. All packets in both directions are     labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized,     and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This     behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no     explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the     Smack documentation claims. (CVE-2024-47659)

  - In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash     on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races     when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on     probe() and if a device-connected packet is received by the hw when the thread running     hidpp_connect_event() from probe() is waiting on the hw, then a second thread running     hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below     code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) {     hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see     this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-     device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device     0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after     this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the     other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if     (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the     battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /*     Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev,     hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps =     devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed     input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input =     hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following     sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ...
    hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we     have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but     this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The     hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points     to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of     the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the     last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The     first registered power supply class device gets unregistered, this involves sending a remove uevent to     userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses     hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep     22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22     20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP:
    0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22     20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ?     power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric     kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- (CVE-2023-52478)

  - In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: h6: Reparent CPUX     during PLL CPUX rate change While PLL CPUX clock rate change when CPU is running from it works in vast     majority of cases, now and then it causes instability. This leads to system crashes and other undefined     behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't     observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.
    (CVE-2023-52882)

  - In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error     handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in     scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative     WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows     for the early termination of problematic sessions. Previously, sessions were only released at the end of     j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 &     while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0     18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done (CVE-2023-52887)

  - In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Only free     buffer VA that is not NULL In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called     only when the buffer to free exists, there are some instances that didn't do the check and triggered     warnings in practice. We believe those checks were forgotten unintentionally. Add the checks back to fix     the warnings. (CVE-2023-52888)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
236878	Ubuntu 18.04 LTS / 20.04 LTS : Linux kernel vulnerabilities (USN-7516-1)	Nessus	Ubuntu Local Security Checks	2025/5/16	2025/5/16	high
237255	Debian dla-4178 : ata-modules-5.10.0-34-armmp-di - security update	Nessus	Debian Local Security Checks	2025/5/26	2025/9/24	high
242830	NewStart CGSL MAIN 7.02 : kernel Multiple Vulnerabilities (NS-SA-2025-0118)	Nessus	NewStart CGSL Local Security Checks	2025/7/25	2026/1/6	high

检测

插件搜索

high

high

high