Here are the latest advisories specifically for Ubuntu Linux:

• USN-7179-1: Linux kernel vulnerabilities
  Andy Nguyen discovered that the Bluetooth L2CAP implementation in the Linux kernel contained a type-confusion error. A physically proximate remote attacker could use this to cause a denial of service (system crash) or possibly execute arbitrary code. (CVE-2020-12351) Andy Nguyen discovered that the Bluetooth A2MP implementation in the Linux kernel did not properly initialize memory in some situations. A physically proximate remote attacker could use this to expose sensitive information (kernel memory). (CVE-2020-12352) Andy Nguyen discovered that the Bluetooth HCI event packet parser in the Linux kernel did not properly handle event advertisements of certain sizes, leading to a heap-based buffer overflow. A physically proximate remote attacker could use this to cause a denial of service (system crash) or possibly execute arbitrary code. (CVE-2020-24490) 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: - GPU drivers; - Media drivers; - Network drivers; - SMB network file system; - Bluetooth subsystem; - Amateur Radio drivers; - Network traffic control; - VMware vSockets driver; (CVE-2024-43904, CVE-2024-35963, CVE-2024-35967, CVE-2024-40973, CVE-2024-26822, CVE-2024-35965, CVE-2024-40910, CVE-2024-38553, CVE-2024-53057, CVE-2024-50264, CVE-2024-35966)
• USN-7173-2: Linux kernel vulnerabilities
  Ziming Zhang discovered that the DRM driver for VMware Virtual GPU did not properly handle certain error conditions, leading to a NULL pointer dereference. A local attacker could possibly trigger this vulnerability to cause a denial of service. (CVE-2022-38096) 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: - GPU drivers; - Network drivers; - SCSI subsystem; - Ext4 file system; - Bluetooth subsystem; - Memory management; - Amateur Radio drivers; - Network traffic control; - Sun RPC protocol; - VMware vSockets driver; (CVE-2023-52821, CVE-2024-40910, CVE-2024-43892, CVE-2024-49967, CVE-2024-50264, CVE-2024-36952, CVE-2024-38553, CVE-2021-47101, CVE-2021-47001, CVE-2024-35965, CVE-2024-35963, CVE-2024-35966, CVE-2024-35967, CVE-2024-53057, CVE-2024-38597)
• USN-7166-3: Linux kernel (HWE) vulnerabilities
  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; - RISC-V architecture; - S390 architecture; - x86 architecture; - Block layer subsystem; - ACPI drivers; - Drivers core; - ATA over ethernet (AOE) driver; - TPM device driver; - Clock framework and drivers; - Buffer Sharing and Synchronization framework; - EFI core; - GPIO subsystem; - GPU drivers; - HID subsystem; - I2C subsystem; - InfiniBand drivers; - Input Device core drivers; - Mailbox framework; - Media drivers; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - Microsoft Azure Network Adapter (MANA) driver; - STMicroelectronics network drivers; - NTB driver; - Virtio pmem driver; - PCI subsystem; - x86 platform drivers; - S/390 drivers; - SCSI subsystem; - SPI subsystem; - Thermal drivers; - USB Device Class drivers; - USB Type-C Port Controller Manager driver; - VFIO drivers; - Virtio Host (VHOST) subsystem; - Framebuffer layer; - 9P distributed file system; - BTRFS file system; - Ceph distributed file system; - File systems infrastructure; - Ext4 file system; - F2FS file system; - GFS2 file system; - JFS file system; - Network file system (NFS) client; - Network file system (NFS) server daemon; - NILFS2 file system; - Network file system (NFS) superblock; - Bluetooth subsystem; - Network traffic control; - Network sockets; - TCP network protocol; - BPF subsystem; - Perf events; - Kernel thread helper (kthread); - Padata parallel execution mechanism; - Arbitrary resource management; - Static call mechanism; - Tracing infrastructure; - Memory management; - Ethernet bridge; - CAN network layer; - Networking core; - IPv4 networking; - IPv6 networking; - MAC80211 subsystem; - Multipath TCP; - Netfilter; - Netlink; - SCTP protocol; - TIPC protocol; - SELinux security module; - Simplified Mandatory Access Control Kernel framework; - AudioScience HPI driver; - Amlogic Meson SoC drivers; - USB sound devices; (CVE-2024-49944, CVE-2024-49907, CVE-2024-50062, CVE-2024-36893, CVE-2024-49985, CVE-2024-49903, CVE-2024-49886, CVE-2024-50180, CVE-2024-47757, CVE-2024-49938, CVE-2024-49902, CVE-2024-47709, CVE-2024-49884, CVE-2024-49967, CVE-2024-49977, CVE-2024-47734, CVE-2024-49954, CVE-2024-49963, CVE-2024-47747, CVE-2024-50008, CVE-2024-47696, CVE-2024-50038, CVE-2024-46695, CVE-2024-47705, CVE-2024-49957, CVE-2024-38538, CVE-2024-50019, CVE-2024-38544, CVE-2024-50003, CVE-2024-50095, CVE-2024-50000, CVE-2024-49981, CVE-2024-49863, CVE-2024-47710, CVE-2024-49983, CVE-2024-26947, CVE-2024-46852, CVE-2024-49871, CVE-2024-49936, CVE-2024-47720, CVE-2024-49881, CVE-2024-47672, CVE-2024-50040, CVE-2024-49997, CVE-2024-50044, CVE-2023-52532, CVE-2024-47740, CVE-2024-44942, CVE-2024-49948, CVE-2023-52621, CVE-2024-49959, CVE-2024-47718, CVE-2024-50188, CVE-2024-47699, CVE-2024-47756, CVE-2024-47723, CVE-2024-46849, CVE-2024-50035, CVE-2024-50189, CVE-2024-47684, CVE-2024-49900, CVE-2024-50024, CVE-2024-49851, CVE-2024-49860, CVE-2024-49924, CVE-2024-49946, CVE-2024-44940, CVE-2023-52904, CVE-2024-47679, CVE-2024-47748, CVE-2023-52917, CVE-2024-47735, CVE-2024-46858, CVE-2024-35904, CVE-2024-47673, CVE-2024-49878, CVE-2024-47739, CVE-2024-49973, CVE-2024-49935, CVE-2024-49875, CVE-2024-49896, CVE-2024-47690, CVE-2024-50007, CVE-2024-49933, CVE-2024-49958, CVE-2024-49913, CVE-2024-49883, CVE-2024-47742, CVE-2024-41016, CVE-2024-50002, CVE-2024-49969, CVE-2024-46853, CVE-2024-50031, CVE-2024-47698, CVE-2024-47749, CVE-2024-50059, CVE-2024-49966, CVE-2024-50093, CVE-2024-27072, CVE-2024-50186, CVE-2024-49895, CVE-2024-38632, CVE-2024-49995, CVE-2024-38545, CVE-2024-38667, CVE-2024-36968, CVE-2024-49952, CVE-2024-50001, CVE-2024-47697, CVE-2024-50045, CVE-2024-49856, CVE-2024-49852, CVE-2024-47712, CVE-2023-52639, CVE-2024-49975, CVE-2024-42158, CVE-2024-49962, CVE-2024-50181, CVE-2024-42156, CVE-2024-46855, CVE-2024-47693, CVE-2024-47670, CVE-2024-47706, CVE-2024-50184, CVE-2024-49965, CVE-2024-39463, CVE-2024-50191, CVE-2024-49866, CVE-2024-49890, CVE-2024-49877, CVE-2024-49879, CVE-2024-49927, CVE-2024-50039, CVE-2024-46859, CVE-2024-47674, CVE-2024-50096, CVE-2024-50013, CVE-2024-46854, CVE-2024-49868, CVE-2024-49882, CVE-2024-47671, CVE-2024-50179, CVE-2024-44931, CVE-2024-50046, CVE-2024-50006, CVE-2024-49892, CVE-2024-49949, CVE-2024-42079, CVE-2024-46865, CVE-2024-47692, CVE-2024-47713, CVE-2024-47701, CVE-2024-49889, CVE-2024-49894, CVE-2024-50015, CVE-2024-49858, CVE-2024-49955, CVE-2024-49867, CVE-2024-35951, CVE-2024-50033, CVE-2024-49982, CVE-2024-47695, CVE-2024-50049, CVE-2024-49930, CVE-2024-50041, CVE-2024-47737, CVE-2024-47685)
• USN-7159-4: Linux kernel (IoT) vulnerabilities
  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; - S390 architecture; - x86 architecture; - Power management core; - GPU drivers; - InfiniBand drivers; - Network drivers; - S/390 drivers; - TTY drivers; - BTRFS file system; - EROFS file system; - F2FS file system; - File systems infrastructure; - BPF subsystem; - Socket messages infrastructure; - Bluetooth subsystem; - Ethernet bridge; - Networking core; - IPv4 networking; - SELinux security module; (CVE-2022-48938, CVE-2024-42156, CVE-2024-36953, CVE-2024-38538, CVE-2021-47501, CVE-2024-42068, CVE-2024-26947, CVE-2024-46724, CVE-2024-36968, CVE-2023-52497, CVE-2024-35951, CVE-2023-52488, CVE-2024-44940, CVE-2022-48733, CVE-2023-52498, CVE-2022-48943, CVE-2024-35904, CVE-2024-42077, CVE-2024-36938, CVE-2023-52639, CVE-2024-42240, CVE-2024-44942, CVE-2021-47076)
• USN-7178-1: DPDK vulnerability
  It was discovered that DPDK incorrectly handled the Vhost library checksum offload feature. An malicious guest could possibly use this issue to cause the hypervisor's vSwitch to crash, resulting in a denial of service.
• LSN-0108-1: Kernel Live Patch Security Notice
  In the Linux kernel, the following vulnerability has been resolved: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new ->async_done flag) that the memory has already been released.)(CVE-2024-26800) In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf ('inet: frag: Always orphan skbs inside ip_defrag()') [.. net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.)(CVE-2024-26921) In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map. This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below). Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache(). Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this): --8try_to_unuse() will stop as soon as soon as si->inuse_pages==0. So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped(). Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries. Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry. Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.] Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()? --8
• USN-7177-1: YARA vulnerability
  It was discovered that YARA did not properly sanitize its configuration settings. An attacker could potentially exploit this issue to cause a denial of service.
• USN-7169-2: Linux kernel (GCP) vulnerabilities
  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: - Ext4 file system; - Network traffic control; - VMware vSockets driver; (CVE-2024-49967, CVE-2024-53057, CVE-2024-50264)
• USN-7172-1: libvpx vulnerability
  It was discovered that libvpx did not properly handle certain malformed media files. If an application using libvpx opened a specially crafted file, a remote attacker could cause a denial of service, or possibly execute arbitrary code. Ubuntu 22.04 LTS, Ubuntu 20.04 LTS, Ubuntu 18.04 LTS, and Ubuntu 16.04 LTS were previously addressed in USN-6403-1, USN-6403-2, and USN-6403-3. This update addresses the issue in Ubuntu 14.04 LTS.
• USN-7176-1: GStreamer Good Plugins vulnerabilities
  Antonio Morales discovered that GStreamer Good Plugins incorrectly handled certain malformed media files. An attacker could use these issues to cause GStreamer Good Plugins to crash, resulting in a denial of service, or possibly execute arbitrary code.
• More...