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

    Chenyuan Yang discovered that the CEC driver driver in the Linux kernel contained a use-after-free     vulnerability. A local attacker could use this to cause a denial of service (system crash) or possibly     execute arbitrary code. (CVE-2024-23848)

    It was discovered that the JFS file system contained an out-of-bounds read vulnerability when printing     xattr debug information. A local attacker could use this to cause a denial of service (system crash).
    (CVE-2024-40902)

    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;

    - MIPS architecture;

    - PA-RISC architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - x86 architecture;

    - Block layer subsystem;

    - ACPI drivers;

    - Drivers core;

    - Null block device driver;

    - Character device driver;

    - TPM device driver;

    - Clock framework and drivers;

    - CPU frequency scaling framework;

    - Hardware crypto device drivers;

    - CXL (Compute Express Link) drivers;

    - Buffer Sharing and Synchronization framework;

    - DMA engine subsystem;

    - EFI core;

    - FPGA Framework;

    - GPU drivers;

    - Greybus drivers;

    - HID subsystem;

    - HW tracing;

    - I2C subsystem;

    - IIO subsystem;

    - InfiniBand drivers;

    - Input Device (Mouse) drivers;

    - Mailbox framework;

    - Media drivers;

    - Microchip PCI driver;

    - VMware VMCI Driver;

    - Network drivers;

    - PCI subsystem;

    - x86 platform drivers;

    - PTP clock framework;

    - S/390 drivers;

    - SCSI drivers;

    - SoundWire subsystem;

    - Sonic Silicon Backplane drivers;

    - Greybus lights staging drivers;

    - Thermal drivers;

    - TTY drivers;

    - USB subsystem;

    - VFIO drivers;

    - Framebuffer layer;

    - Watchdog drivers;

    - 9P distributed file system;

    - BTRFS file system;

    - File systems infrastructure;

    - Ext4 file system;

    - F2FS file system;

    - JFS file system;

    - Network file system server daemon;

    - NILFS2 file system;

    - NTFS3 file system;

    - SMB network file system;

    - Tracing file system;

    - Tracing infrastructure;

    - io_uring subsystem;

    - Core kernel;

    - BPF subsystem;

    - Kernel debugger infrastructure;

    - DMA mapping infrastructure;

    - IRQ subsystem;

    - Memory management;

    - 9P file system network protocol;

    - Amateur Radio drivers;

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

    - Ethernet bridge;

    - Networking core;

    - Ethtool driver;

    - IPv4 networking;

    - IPv6 networking;

    - MAC80211 subsystem;

    - Multipath TCP;

    - Netfilter;

    - NET/ROM layer;

    - NFC subsystem;

    - Network traffic control;

    - Sun RPC protocol;

    - TIPC protocol;

    - TLS protocol;

    - Unix domain sockets;

    - Wireless networking;

    - XFRM subsystem;

    - AppArmor security module;

    - Integrity Measurement Architecture(IMA) framework;

    - Landlock security;

    - Linux Security Modules (LSM) Framework;

    - SELinux security module;

    - Simplified Mandatory Access Control Kernel framework;

    - ALSA framework;

    - HD-audio driver;

    - SOF drivers;

    - KVM core; (CVE-2024-40911, CVE-2024-37356, CVE-2024-40935, CVE-2024-40944, CVE-2024-41003,     CVE-2024-40990, CVE-2024-40952, CVE-2024-40940, CVE-2024-40930, CVE-2024-40985, CVE-2024-40941,     CVE-2024-38630, CVE-2024-39466, CVE-2024-40933, CVE-2024-38624, CVE-2024-40924, CVE-2024-40945,     CVE-2024-40899, CVE-2024-38622, CVE-2024-40979, CVE-2024-36484, CVE-2024-41004, CVE-2024-39474,     CVE-2022-48772, CVE-2024-36244, CVE-2024-38664, CVE-2024-40925, CVE-2024-40980, CVE-2024-39480,     CVE-2024-36270, CVE-2024-40936, CVE-2024-40904, CVE-2024-38635, CVE-2024-40927, CVE-2024-36481,     CVE-2024-40929, CVE-2024-40958, CVE-2024-36978, CVE-2024-40992, CVE-2024-40908, CVE-2024-39504,     CVE-2024-41001, CVE-2024-40967, CVE-2023-52884, CVE-2024-40997, CVE-2024-40903, CVE-2024-40913,     CVE-2024-34030, CVE-2024-39473, CVE-2024-40966, CVE-2024-40951, CVE-2024-40902, CVE-2024-40982,     CVE-2024-40923, CVE-2024-39467, CVE-2024-40910, CVE-2024-40909, CVE-2024-39463, CVE-2024-40974,     CVE-2024-41002, CVE-2024-39464, CVE-2024-39496, CVE-2024-41040, CVE-2024-39469, CVE-2024-39500,     CVE-2024-39510, CVE-2024-38627, CVE-2024-32936, CVE-2024-40975, CVE-2024-38390, CVE-2024-40959,     CVE-2024-41006, CVE-2024-40986, CVE-2024-40987, CVE-2024-40922, CVE-2024-40983, CVE-2024-37354,     CVE-2024-38637, CVE-2024-39277, CVE-2024-40943, CVE-2024-39371, CVE-2024-40921, CVE-2024-40953,     CVE-2024-38634, CVE-2024-38659, CVE-2024-39492, CVE-2024-40976, CVE-2024-40906, CVE-2024-40965,     CVE-2024-38667, CVE-2024-39498, CVE-2024-38628, CVE-2024-38661, CVE-2024-38663, CVE-2024-40998,     CVE-2024-40948, CVE-2024-38306, CVE-2024-40928, CVE-2024-39468, CVE-2024-39494, CVE-2024-39505,     CVE-2024-40963, CVE-2024-39499, CVE-2024-39506, CVE-2024-40995, CVE-2024-39491, CVE-2024-40900,     CVE-2024-39478, CVE-2024-39490, CVE-2024-39291, CVE-2024-40981, CVE-2024-40926, CVE-2024-40939,     CVE-2024-38385, CVE-2024-39483, CVE-2024-40989, CVE-2024-40955, CVE-2024-39501, CVE-2024-38381,     CVE-2024-33621, CVE-2024-40964, CVE-2024-42148, CVE-2024-36286, CVE-2024-38629, CVE-2024-39509,     CVE-2024-39298, CVE-2024-36489, CVE-2024-34777, CVE-2024-40957, CVE-2024-40919, CVE-2024-39462,     CVE-2024-39495, CVE-2024-39497, CVE-2024-38636, CVE-2024-36281, CVE-2024-39479, CVE-2024-40932,     CVE-2024-36288, CVE-2024-38623, CVE-2024-40969, CVE-2024-40931, CVE-2024-36971, CVE-2024-40934,     CVE-2024-36015, CVE-2024-39485, CVE-2024-40996, CVE-2024-39507, CVE-2024-36973, CVE-2024-38625,     CVE-2024-39301, CVE-2024-34027, CVE-2024-37026, CVE-2024-40960, CVE-2024-37078, CVE-2024-40912,     CVE-2024-40988, CVE-2024-41005, CVE-2024-39276, CVE-2024-38662, CVE-2024-39502, CVE-2024-36479,     CVE-2024-40947, CVE-2024-38780, CVE-2024-38388, CVE-2024-40917, CVE-2024-36974, CVE-2024-40970,     CVE-2024-40901, CVE-2024-38384, CVE-2024-39475, CVE-2024-40949, CVE-2024-37021, CVE-2024-38633,     CVE-2024-39503, CVE-2024-41000, CVE-2024-33847, CVE-2024-35247, CVE-2024-40968, CVE-2024-33619,     CVE-2024-38619, CVE-2024-40984, CVE-2024-36478, CVE-2024-39493, CVE-2024-42078, CVE-2024-40954,     CVE-2024-40978, CVE-2024-39508, CVE-2024-40915, CVE-2024-39489, CVE-2024-40920, CVE-2024-38618,     CVE-2024-40938, CVE-2024-39296, CVE-2024-40962, CVE-2024-39470, CVE-2024-39481, CVE-2024-40977,     CVE-2024-38621, CVE-2024-40971, CVE-2024-31076, CVE-2024-36972, CVE-2024-39471, CVE-2024-40994,     CVE-2024-40973, CVE-2024-40916, CVE-2024-40942, CVE-2024-40956, CVE-2024-39465, CVE-2024-40914,     CVE-2024-40937, CVE-2024-40918, CVE-2024-40905, CVE-2024-39488, CVE-2024-38632, CVE-2024-39461,     CVE-2024-40999, CVE-2024-40972, CVE-2024-36477, CVE-2024-40961)

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 Ubuntu 24.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-7005-1 advisory.

    Chenyuan Yang discovered that the CEC driver driver in the Linux kernel contained a use-after-free     vulnerability. A local attacker could use this to cause a denial of service (system crash) or possibly     execute arbitrary code. (CVE-2024-23848)

    It was discovered that the JFS file system contained an out-of-bounds read vulnerability when printing     xattr debug information. A local attacker could use this to cause a denial of service (system crash).
    (CVE-2024-40902)

    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;

    - MIPS architecture;

    - PA-RISC architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - x86 architecture;

    - Block layer subsystem;

    - ACPI drivers;

    - Drivers core;

    - Null block device driver;

    - Character device driver;

    - Clock framework and drivers;

    - CPU frequency scaling framework;

    - Hardware crypto device drivers;

    - CXL (Compute Express Link) drivers;

    - Buffer Sharing and Synchronization framework;

    - DMA engine subsystem;

    - EFI core;

    - FPGA Framework;

    - GPU drivers;

    - Greybus drivers;

    - HID subsystem;

    - HW tracing;

    - I2C subsystem;

    - IIO subsystem;

    - InfiniBand drivers;

    - Input Device (Mouse) drivers;

    - Mailbox framework;

    - Media drivers;

    - Microchip PCI driver;

    - VMware VMCI Driver;

    - Network drivers;

    - PCI subsystem;

    - x86 platform drivers;

    - PTP clock framework;

    - S/390 drivers;

    - SCSI drivers;

    - SoundWire subsystem;

    - Sonic Silicon Backplane drivers;

    - Greybus lights staging drivers;

    - Thermal drivers;

    - TTY drivers;

    - USB subsystem;

    - VFIO drivers;

    - Framebuffer layer;

    - Watchdog drivers;

    - 9P distributed file system;

    - BTRFS file system;

    - File systems infrastructure;

    - Ext4 file system;

    - F2FS file system;

    - JFS file system;

    - Network file system server daemon;

    - NILFS2 file system;

    - NTFS3 file system;

    - SMB network file system;

    - Tracing file system;

    - IOMMU subsystem;

    - Tracing infrastructure;

    - io_uring subsystem;

    - Core kernel;

    - BPF subsystem;

    - Kernel debugger infrastructure;

    - DMA mapping infrastructure;

    - IRQ subsystem;

    - Memory management;

    - 9P file system network protocol;

    - Amateur Radio drivers;

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

    - Ethernet bridge;

    - Networking core;

    - Ethtool driver;

    - IPv4 networking;

    - IPv6 networking;

    - MAC80211 subsystem;

    - Multipath TCP;

    - Netfilter;

    - NET/ROM layer;

    - NFC subsystem;

    - Network traffic control;

    - Sun RPC protocol;

    - TIPC protocol;

    - TLS protocol;

    - Unix domain sockets;

    - Wireless networking;

    - XFRM subsystem;

    - AppArmor security module;

    - Integrity Measurement Architecture(IMA) framework;

    - Landlock security;

    - Linux Security Modules (LSM) Framework;

    - SELinux security module;

    - Simplified Mandatory Access Control Kernel framework;

    - ALSA framework;

    - HD-audio driver;

    - SOF drivers;

    - KVM core; (CVE-2024-40963, CVE-2024-40994, CVE-2024-36481, CVE-2024-39301, CVE-2024-38390,     CVE-2024-40976, CVE-2024-40934, CVE-2024-40902, CVE-2024-40916, CVE-2024-39298, CVE-2024-38659,     CVE-2024-38384, CVE-2024-38635, CVE-2024-39494, CVE-2024-40926, CVE-2024-40956, CVE-2024-40948,     CVE-2024-40920, CVE-2024-38624, CVE-2024-39498, CVE-2024-38780, CVE-2024-39503, CVE-2024-40919,     CVE-2024-39505, CVE-2024-40988, CVE-2024-36972, CVE-2024-36974, CVE-2024-39495, CVE-2024-40992,     CVE-2024-36015, CVE-2024-38618, CVE-2024-39478, CVE-2024-40975, CVE-2024-39507, CVE-2024-39479,     CVE-2024-39291, CVE-2024-40925, CVE-2024-39493, CVE-2024-41005, CVE-2024-40932, CVE-2024-39467,     CVE-2024-40973, CVE-2024-38634, CVE-2024-34027, CVE-2024-39462, CVE-2024-40949, CVE-2024-40908,     CVE-2024-40929, CVE-2024-38662, CVE-2024-39489, CVE-2024-40953, CVE-2024-38306, CVE-2024-40915,     CVE-2024-39470, CVE-2024-40969, CVE-2024-31076, CVE-2024-38663, CVE-2024-38629, CVE-2024-38633,     CVE-2024-40959, CVE-2024-39475, CVE-2024-40947, CVE-2024-40971, CVE-2024-40979, CVE-2024-40996,     CVE-2024-36484, CVE-2024-40960, CVE-2022-48772, CVE-2024-33619, CVE-2024-40923, CVE-2024-41006,     CVE-2024-39474, CVE-2024-40944, CVE-2024-39473, CVE-2024-39469, CVE-2024-40914, CVE-2024-40900,     CVE-2023-52884, CVE-2024-40931, CVE-2024-38664, CVE-2024-41004, CVE-2024-38636, CVE-2024-41001,     CVE-2024-39497, CVE-2024-40974, CVE-2024-42078, CVE-2024-40954, CVE-2024-39483, CVE-2024-40978,     CVE-2024-40952, CVE-2024-39481, CVE-2024-40955, CVE-2024-39471, CVE-2024-41000, CVE-2024-40972,     CVE-2024-40957, CVE-2024-40913, CVE-2024-36478, CVE-2024-40984, CVE-2024-40990, CVE-2024-39510,     CVE-2024-38381, CVE-2024-39277, CVE-2024-39464, CVE-2024-40995, CVE-2024-40905, CVE-2024-40986,     CVE-2024-36971, CVE-2024-39480, CVE-2024-40938, CVE-2024-39509, CVE-2024-40982, CVE-2024-39500,     CVE-2024-37026, CVE-2024-40965, CVE-2024-40961, CVE-2024-40989, CVE-2024-36973, CVE-2024-39504,     CVE-2024-37354, CVE-2024-39488, CVE-2024-38661, CVE-2024-40998, CVE-2024-36489, CVE-2024-37021,     CVE-2024-40917, CVE-2024-36281, CVE-2024-40964, CVE-2024-39496, CVE-2024-40980, CVE-2024-39465,     CVE-2024-40983, CVE-2024-40936, CVE-2024-40899, CVE-2024-40933, CVE-2024-36288, CVE-2024-36286,     CVE-2024-40987, CVE-2024-40939, CVE-2024-38667, CVE-2024-38628, CVE-2024-40977, CVE-2024-39276,     CVE-2024-40941, CVE-2024-39491, CVE-2024-37078, CVE-2024-36978, CVE-2024-38623, CVE-2024-40962,     CVE-2024-40935, CVE-2024-40997, CVE-2024-40981, CVE-2024-40922, CVE-2024-39461, CVE-2024-40999,     CVE-2024-40918, CVE-2024-40927, CVE-2024-42148, CVE-2024-39371, CVE-2024-40985, CVE-2024-34030,     CVE-2024-39485, CVE-2024-39296, CVE-2024-39466, CVE-2024-40909, CVE-2024-39492, CVE-2024-39502,     CVE-2024-40903, CVE-2024-41040, CVE-2024-40968, CVE-2024-41003, CVE-2024-39499, CVE-2024-39508,     CVE-2024-34777, CVE-2024-38627, CVE-2024-40930, CVE-2024-38388, CVE-2024-39490, CVE-2024-40906,     CVE-2024-40940, CVE-2024-40937, CVE-2024-40911, CVE-2024-38385, CVE-2024-36244, CVE-2024-38622,     CVE-2024-40958, CVE-2024-41002, CVE-2024-38621, CVE-2024-40970, CVE-2024-40904, CVE-2024-40928,     CVE-2024-40967, CVE-2024-40951, CVE-2024-38637, CVE-2024-37356, CVE-2024-39463, CVE-2024-40912,     CVE-2024-33847, CVE-2024-39468, CVE-2024-40942, CVE-2024-40910, CVE-2024-38625, CVE-2024-35247,     CVE-2024-36479, CVE-2024-40943, CVE-2024-32936, CVE-2024-38630, CVE-2024-39501, CVE-2024-40966,     CVE-2024-40921, CVE-2024-40924, CVE-2024-39506, CVE-2024-36270, CVE-2024-33621, CVE-2024-40945,     CVE-2024-40901, CVE-2024-38632, CVE-2024-38619)

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 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.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-516.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer     corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented     packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to     calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing     changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in     rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.
    (CVE-2024-38586)

  - In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Avoid unnecessary     destruction of file_ida file_ida is allocated during cdev open and is freed accordingly during cdev     release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an     already empty file_ida when the WQ cdev is removed. Worse, ida_free() in cdev release may happen after     destruction of file_ida per WQ cdev. This can lead to accessing an id in file_ida after it has been     destroyed, resulting in a kernel panic. Remove ida_destroy(&file_ida) to address these issues.
    (CVE-2024-38629)

  - In the Linux kernel, the following vulnerability has been resolved: ionic: fix kernel panic in XDP_TX     action In the XDP_TX path, ionic driver sends a packet to the TX path with rx page and corresponding dma     address. After tx is done, ionic_tx_clean() frees that page. But RX ring buffer isn't reset to NULL. So,     it uses a freed page, which causes kernel panic. BUG: unable to handle page fault for address:
    ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Oops: Oops:
    0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comm: ksoftirqd/1 Not tainted 6.9.0+ #11     Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP:
    0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f Code: 00 53 41 55 41 56 41 57 b8 01 00 00 00 48     8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX:
    0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048     RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09: ffffed1027a04a23 R10:
    0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100     R15: 00000001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0     PKRU: 55555554 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x254/0x790 ?
    __pfx_page_fault_oops+0x10/0x10 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ?     search_bpf_extables+0x165/0x260 ? fixup_exception+0x4a/0x970 ? exc_page_fault+0xcb/0xe0 ?     asm_exc_page_fault+0x22/0x30 ? 0xffffffffc0051f64 ? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f     ? do_raw_spin_unlock+0x54/0x220 ionic_rx_service+0x11ab/0x3010 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_clean+0x29b/0xc60 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_tx_clean+0x10/0x10 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_cq_service+0x25d/0xa00 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_cq_service+0x69/0x150 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_txrx_napi+0x11a/0x540 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x7e7/0xc30 ?
    __pfx_net_rx_action+0x10/0x10 (CVE-2024-40907)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix missing lock on sync     reset reload On sync reset reload work, when remote host updates devlink on reload actions performed on     that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which     results in triggering lock assert like the following: WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261     devl_assert_locked+0x3e/0x50  CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116     Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events     mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50  Call Trace: <TASK> ?
    __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ?     exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? devl_assert_locked+0x3e/0x50     devlink_notify+0x88/0x2b0 ? mlx5_attach_device+0x20c/0x230 [mlx5_core] ? __pfx_devlink_notify+0x10/0x10 ?     process_one_work+0x4b6/0xbb0 process_one_work+0x4b6/0xbb0 [] (CVE-2024-42268)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: Return non-zero value from     tipc_udp_addr2str() on error tipc_udp_addr2str() should return non-zero value if the UDP media address is     invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning     1 on an invalid UDP media address. (CVE-2024-42284)

  - In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in     dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for     reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation.
    Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and     add it to the devres list. If this happens, there will be two entries in the devres list with the same     vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by     destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption     http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 (CVE-2024-43856)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix CT entry update leaks     of modify header context The cited commit allocates a new modify header to replace the old one when     updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support,     modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify     header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fix it by     restoring the old attr to attr when failed to allocate a new modify header context. So when the CT entry     is freed, the right modify header context will be freed. And the panic of accessing error pointer is also     fixed. (CVE-2024-43864)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in     shutdown callback There is no point in recovery during device shutdown. if health work started need to     wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback.
    (CVE-2024-43866)

  - In the Linux kernel, the following vulnerability has been resolved: memcg: protect concurrent access to     mem_cgroup_idr Commit 73f576c04b94 (mm: memcontrol: fix cgroup creation failure after many small jobs)     decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to     maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For     the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected     through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not     protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt     to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a     long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del()     and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the     super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were     either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed     to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases.
    Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr     and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So,     the most reasonable explanation is that these situations can happen due to race between multiple     idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing     multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the     system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing     list_lru_one. (CVE-2024-43892)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix invalid WQ     linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ     linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the     same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the     same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without     unlinking the WQE again. (CVE-2024-44970)

  - In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix double DMA unmapping for     XDP_REDIRECT Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should     have been removed when we let the page pool handle the DMA mapping. This bug causes the warning: WARNING:
    CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm:
    ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS     2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4     08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08     5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX:
    0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000     RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10:
    ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000     R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0     ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ?     handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ?     iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ?     bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en]     bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en]
    __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0 (CVE-2024-44984)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix validity interception     issue when gisa is switched off We might run into a SIE validity if gisa has been disabled either via     using kernel parameter kvm.use_gisa=0 or by setting the related sysfs attribute to N (echo N     >/sys/module/kvm/parameters/use_gisa). The validity is caused by an invalid value in the SIE control     block's gisa designation. That happens because we pass the uninitialized gisa origin to virt_to_phys()     before writing it to the gisa designation. To fix this we return 0 in kvm_s390_get_gisa_desc() if the     origin is 0. kvm_s390_get_gisa_desc() is used to determine which gisa designation to set in the SIE     control block. A value of 0 in the gisa designation disables gisa usage. The issue surfaces in the host     kernel with the following kernel message as soon a new kvm guest start is attemted. kvm: unhandled     validity intercept 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101     kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE     xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core     irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet     nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct     nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs     ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel     drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390     prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390     sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc     scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm:
    CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW :
    0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1     W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028     000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000     000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e     00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118:
    c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea     lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1     000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call     Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>]     kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm]     [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430     [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70     [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0     [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>]
    __warn_printk+0xe8/0xf0 (CVE-2024-45005)

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

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

    Chenyuan Yang discovered that the CEC driver driver in the Linux kernel contained a use-after-free     vulnerability. A local attacker could use this to cause a denial of service (system crash) or possibly     execute arbitrary code. (CVE-2024-23848)

    It was discovered that the JFS file system contained an out-of-bounds read vulnerability when printing     xattr debug information. A local attacker could use this to cause a denial of service (system crash).
    (CVE-2024-40902)

    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;

    - MIPS architecture;

    - PA-RISC architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - User-Mode Linux (UML);

    - x86 architecture;

    - Block layer subsystem;

    - ACPI drivers;

    - Drivers core;

    - Null block device driver;

    - Character device driver;

    - TPM device driver;

    - Clock framework and drivers;

    - CPU frequency scaling framework;

    - Hardware crypto device drivers;

    - CXL (Compute Express Link) drivers;

    - Buffer Sharing and Synchronization framework;

    - DMA engine subsystem;

    - EFI core;

    - FPGA Framework;

    - GPU drivers;

    - Greybus drivers;

    - HID subsystem;

    - HW tracing;

    - I2C subsystem;

    - IIO subsystem;

    - InfiniBand drivers;

    - Input Device (Mouse) drivers;

    - Mailbox framework;

    - Media drivers;

    - Microchip PCI driver;

    - VMware VMCI Driver;

    - MMC subsystem;

    - Network drivers;

    - PCI subsystem;

    - x86 platform drivers;

    - PTP clock framework;

    - S/390 drivers;

    - SCSI drivers;

    - SoundWire subsystem;

    - Sonic Silicon Backplane drivers;

    - Greybus lights staging drivers;

    - Thermal drivers;

    - TTY drivers;

    - USB subsystem;

    - VFIO drivers;

    - Framebuffer layer;

    - Watchdog drivers;

    - 9P distributed file system;

    - BTRFS file system;

    - File systems infrastructure;

    - Ext4 file system;

    - F2FS file system;

    - JFS file system;

    - Network file system server daemon;

    - NILFS2 file system;

    - NTFS3 file system;

    - SMB network file system;

    - Tracing file system;

    - IOMMU subsystem;

    - Tracing infrastructure;

    - io_uring subsystem;

    - Core kernel;

    - BPF subsystem;

    - Kernel debugger infrastructure;

    - DMA mapping infrastructure;

    - IRQ subsystem;

    - Memory management;

    - 9P file system network protocol;

    - Amateur Radio drivers;

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

    - Ethernet bridge;

    - Networking core;

    - Ethtool driver;

    - IPv4 networking;

    - IPv6 networking;

    - MAC80211 subsystem;

    - Multipath TCP;

    - Netfilter;

    - NET/ROM layer;

    - NFC subsystem;

    - Network traffic control;

    - Sun RPC protocol;

    - TIPC protocol;

    - TLS protocol;

    - Unix domain sockets;

    - Wireless networking;

    - XFRM subsystem;

    - AppArmor security module;

    - Integrity Measurement Architecture(IMA) framework;

    - Landlock security;

    - Linux Security Modules (LSM) Framework;

    - SELinux security module;

    - Simplified Mandatory Access Control Kernel framework;

    - ALSA framework;

    - HD-audio driver;

    - SOF drivers;

    - KVM core; (CVE-2024-38623, CVE-2024-38662, CVE-2024-39484, CVE-2024-42148, CVE-2024-39493,     CVE-2024-38637, CVE-2024-40962, CVE-2024-36281, CVE-2024-40922, CVE-2024-40958, CVE-2024-40920,     CVE-2024-40986, CVE-2024-40929, CVE-2024-40967, CVE-2024-39296, CVE-2024-40900, CVE-2024-40995,     CVE-2024-40974, CVE-2024-40942, CVE-2024-39464, CVE-2024-40916, CVE-2024-40952, CVE-2024-40997,     CVE-2024-41004, CVE-2024-40970, CVE-2024-40911, CVE-2024-40972, CVE-2024-36477, CVE-2024-40996,     CVE-2024-40988, CVE-2024-38619, CVE-2024-40998, CVE-2024-38627, CVE-2024-36971, CVE-2024-37021,     CVE-2024-40989, CVE-2024-40947, CVE-2024-40957, CVE-2024-39508, CVE-2024-41005, CVE-2024-40931,     CVE-2024-34777, CVE-2024-38633, CVE-2024-38663, CVE-2024-36288, CVE-2024-40955, CVE-2024-40973,     CVE-2024-39483, CVE-2024-38388, CVE-2024-40976, CVE-2024-38622, CVE-2024-40915, CVE-2024-38661,     CVE-2024-38306, CVE-2024-39507, CVE-2024-38659, CVE-2024-40980, CVE-2024-39301, CVE-2024-40945,     CVE-2024-39461, CVE-2024-40948, CVE-2024-39465, CVE-2024-38667, CVE-2024-39498, CVE-2024-39470,     CVE-2024-38629, CVE-2024-40984, CVE-2024-38381, CVE-2024-40903, CVE-2024-38636, CVE-2024-36478,     CVE-2023-52884, CVE-2024-40906, CVE-2024-39371, CVE-2024-38384, CVE-2024-40938, CVE-2024-36978,     CVE-2024-39502, CVE-2024-39291, CVE-2024-39473, CVE-2024-40956, CVE-2024-38618, CVE-2024-40992,     CVE-2024-40944, CVE-2024-39495, CVE-2024-39494, CVE-2024-38632, CVE-2024-38390, CVE-2024-39497,     CVE-2024-40899, CVE-2024-40939, CVE-2024-36481, CVE-2024-40977, CVE-2024-40961, CVE-2024-33847,     CVE-2024-40963, CVE-2024-39276, CVE-2024-40902, CVE-2024-40971, CVE-2024-39485, CVE-2024-40930,     CVE-2024-40985, CVE-2024-39501, CVE-2024-40960, CVE-2024-39503, CVE-2024-40909, CVE-2024-36973,     CVE-2024-36489, CVE-2024-40928, CVE-2024-34027, CVE-2024-40914, CVE-2024-40925, CVE-2024-39500,     CVE-2024-39292, CVE-2024-40987, CVE-2024-39480, CVE-2024-40934, CVE-2024-36270, CVE-2024-38780,     CVE-2024-39479, CVE-2024-39462, CVE-2024-40966, CVE-2024-39510, CVE-2024-39471, CVE-2024-39505,     CVE-2024-37078, CVE-2024-40913, CVE-2024-37356, CVE-2024-38624, CVE-2024-40917, CVE-2024-39506,     CVE-2024-40943, CVE-2024-38625, CVE-2024-38664, CVE-2024-40901, CVE-2024-40964, CVE-2024-40924,     CVE-2024-40918, CVE-2024-36974, CVE-2022-48772, CVE-2024-39509, CVE-2024-38385, CVE-2024-40994,     CVE-2024-39469, CVE-2024-40905, CVE-2024-35247, CVE-2024-41006, CVE-2024-40965, CVE-2024-40932,     CVE-2024-39491, CVE-2024-39499, CVE-2024-40908, CVE-2024-36972, CVE-2024-37026, CVE-2024-40968,     CVE-2024-36244, CVE-2024-39468, CVE-2024-39489, CVE-2024-33621, CVE-2024-40951, CVE-2024-39481,     CVE-2024-40959, CVE-2024-40935, CVE-2024-40927, CVE-2024-40912, CVE-2024-36479, CVE-2024-39467,     CVE-2024-34030, CVE-2024-41003, CVE-2024-40936, CVE-2024-39474, CVE-2024-40969, CVE-2024-40904,     CVE-2024-40937, CVE-2024-40978, CVE-2024-40983, CVE-2024-40910, CVE-2024-39466, CVE-2024-40949,     CVE-2024-39478, CVE-2024-40999, CVE-2024-33619, CVE-2024-38621, CVE-2024-40981, CVE-2024-39475,     CVE-2024-40954, CVE-2024-41000, CVE-2024-39496, CVE-2024-40926, CVE-2024-41040, CVE-2024-39298,     CVE-2024-38635, CVE-2024-39492, CVE-2024-38628, CVE-2024-39504, CVE-2024-42078, CVE-2024-41001,     CVE-2024-39463, CVE-2024-36286, CVE-2024-36484, CVE-2024-40990, CVE-2024-31076, CVE-2024-38630,     CVE-2024-40979, CVE-2024-36015, CVE-2024-40923, CVE-2024-40921, CVE-2024-41002, CVE-2024-40940,     CVE-2024-40975, CVE-2024-40953, CVE-2024-40933, CVE-2024-37354, CVE-2024-40982, CVE-2024-38634,     CVE-2024-39490, CVE-2024-39277, CVE-2024-39488, CVE-2024-40941, CVE-2024-32936, CVE-2024-40919)

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.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
206987	Ubuntu 24.04 LTS : Linux kernel vulnerabilities (USN-6999-1)	Nessus	Ubuntu Local Security Checks	2024/9/11	2026/6/3	high
207096	Ubuntu 24.04 LTS : Linux kernel vulnerabilities (USN-7005-1)	Nessus	Ubuntu Local Security Checks	2024/9/12	2026/6/3	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
208962	CentOS 9 : kernel-5.14.0-516.el9	Nessus	CentOS Local Security Checks	2024/10/14	2024/10/14	high
207235	Ubuntu 22.04 LTS : Linux kernel vulnerabilities (USN-7008-1)	Nessus	Ubuntu Local Security Checks	2024/9/13	2025/9/24	high
210815	RHEL 9 : kernel (RHSA-2024:9315)	Nessus	Red Hat Local Security Checks	2024/11/12	2026/3/24	high

检测

插件搜索

high

high

high

high

high

high