{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-5.4.0-204", "linux-headers-5.4.0-204-generic-lpae", "linux-image-5.4.0-204-generic-lpae", "linux-modules-5.4.0-204-generic-lpae" ], "removed": [ "linux-headers-5.4.0-202", "linux-headers-5.4.0-202-generic-lpae", "linux-image-5.4.0-202-generic-lpae", "linux-modules-5.4.0-202-generic-lpae" ], "diff": [ "cloud-init", "curl", "libcurl3-gnutls:armhf", "libcurl4:armhf", "linux-generic-lpae", "linux-headers-generic-lpae", "linux-image-generic-lpae" ] } }, "diff": { "deb": [ { "name": "cloud-init", "from_version": { "source_package_name": "cloud-init", "source_package_version": "24.3.1-0ubuntu0~20.04.1", "version": "24.3.1-0ubuntu0~20.04.1" }, "to_version": { "source_package_name": "cloud-init", "source_package_version": "24.4-0ubuntu1~20.04.1", "version": "24.4-0ubuntu1~20.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2089577 ], "changes": [ { "cves": [], "log": [ "", " * add d/p/grub-dpkg-support.patch", " - Revert the removal of grub-dpkg from default modules", " * Move d/p/drop-unsupported-systemd-condition-environment.patch", " later in series and refresh as to not be overwritten by", " no-single-process.patch", " * refresh patches:", " - d/p/cli-retain-file-argument-as-main-cmd-arg.patch", " - d/p/expire-on-hashed-users.patch", " - d/p/keep-dhclient-as-priority-client.patch", " - d/p/netplan99-cannot-use-default.patch", " - d/p/no-nocloud-network.patch", " - d/p/no-single-process.patch", " - d/p/revert-551f560d-cloud-config-after-snap-seeding.patch", " - d/p/status-do-not-remove-duplicated-data.patch", " * Upstream snapshot based on 24.4. (LP: #2089577).", " List of changes from upstream can be found at", " https://raw.githubusercontent.com/canonical/cloud-init/24.4/ChangeLog", "" ], "package": "cloud-init", "version": "24.4-0ubuntu1~20.04.1", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 2089577 ], "author": "James Falcon ", "date": "Mon, 25 Nov 2024 11:53:40 -0600" } ], "notes": null }, { "name": "curl", "from_version": { "source_package_name": "curl", "source_package_version": "7.68.0-1ubuntu2.24", "version": "7.68.0-1ubuntu2.24" }, "to_version": { "source_package_name": "curl", "source_package_version": "7.68.0-1ubuntu2.25", "version": "7.68.0-1ubuntu2.25" }, "cves": [ { "cve": "CVE-2024-11053", "url": "https://ubuntu.com/security/CVE-2024-11053", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password.", "cve_priority": "low", "cve_public_date": "2024-12-11 08:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-11053", "url": "https://ubuntu.com/security/CVE-2024-11053", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password.", "cve_priority": "low", "cve_public_date": "2024-12-11 08:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: netrc and redirect credential leak", " - debian/patches/CVE-2024-11053.patch: address several netrc parser", " flaws in lib/netrc.c, lib/url.c, tests/data/Makefile.inc,", " tests/data/test478, tests/data/test479, tests/data/test480,", " tests/unit/unit1304.c, tests/data/DISABLED.", " - CVE-2024-11053", "" ], "package": "curl", "version": "7.68.0-1ubuntu2.25", "urgency": "medium", "distributions": "focal-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Dec 2024 13:26:38 -0500" } ], "notes": null }, { "name": "libcurl3-gnutls:armhf", "from_version": { "source_package_name": "curl", "source_package_version": "7.68.0-1ubuntu2.24", "version": "7.68.0-1ubuntu2.24" }, "to_version": { "source_package_name": "curl", "source_package_version": "7.68.0-1ubuntu2.25", "version": "7.68.0-1ubuntu2.25" }, "cves": [ { "cve": "CVE-2024-11053", "url": "https://ubuntu.com/security/CVE-2024-11053", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password.", "cve_priority": "low", "cve_public_date": "2024-12-11 08:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-11053", "url": "https://ubuntu.com/security/CVE-2024-11053", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password.", "cve_priority": "low", "cve_public_date": "2024-12-11 08:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: netrc and redirect credential leak", " - debian/patches/CVE-2024-11053.patch: address several netrc parser", " flaws in lib/netrc.c, lib/url.c, tests/data/Makefile.inc,", " tests/data/test478, tests/data/test479, tests/data/test480,", " tests/unit/unit1304.c, tests/data/DISABLED.", " - CVE-2024-11053", "" ], "package": "curl", "version": "7.68.0-1ubuntu2.25", "urgency": "medium", "distributions": "focal-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Dec 2024 13:26:38 -0500" } ], "notes": null }, { "name": "libcurl4:armhf", "from_version": { "source_package_name": "curl", "source_package_version": "7.68.0-1ubuntu2.24", "version": "7.68.0-1ubuntu2.24" }, "to_version": { "source_package_name": "curl", "source_package_version": "7.68.0-1ubuntu2.25", "version": "7.68.0-1ubuntu2.25" }, "cves": [ { "cve": "CVE-2024-11053", "url": "https://ubuntu.com/security/CVE-2024-11053", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password.", "cve_priority": "low", "cve_public_date": "2024-12-11 08:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-11053", "url": "https://ubuntu.com/security/CVE-2024-11053", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password.", "cve_priority": "low", "cve_public_date": "2024-12-11 08:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: netrc and redirect credential leak", " - debian/patches/CVE-2024-11053.patch: address several netrc parser", " flaws in lib/netrc.c, lib/url.c, tests/data/Makefile.inc,", " tests/data/test478, tests/data/test479, tests/data/test480,", " tests/unit/unit1304.c, tests/data/DISABLED.", " - CVE-2024-11053", "" ], "package": "curl", "version": "7.68.0-1ubuntu2.25", "urgency": "medium", "distributions": "focal-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 11 Dec 2024 13:26:38 -0500" } ], "notes": null }, { "name": "linux-generic-lpae", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.202.198", "version": "5.4.0.202.198" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.204.200", "version": "5.4.0.204.200" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.4.0-204", "" ], "package": "linux-meta", "version": "5.4.0.204.200", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Thu, 05 Dec 2024 12:37:06 +0100" }, { "cves": [], "log": [ "", " * Bump ABI 5.4.0-203", "" ], "package": "linux-meta", "version": "5.4.0.203.199", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Sat, 30 Nov 2024 20:09:02 +0100" } ], "notes": null }, { "name": "linux-headers-generic-lpae", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.202.198", "version": "5.4.0.202.198" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.204.200", "version": "5.4.0.204.200" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.4.0-204", "" ], "package": "linux-meta", "version": "5.4.0.204.200", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Thu, 05 Dec 2024 12:37:06 +0100" }, { "cves": [], "log": [ "", " * Bump ABI 5.4.0-203", "" ], "package": "linux-meta", "version": "5.4.0.203.199", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Sat, 30 Nov 2024 20:09:02 +0100" } ], "notes": null }, { "name": "linux-image-generic-lpae", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.202.198", "version": "5.4.0.202.198" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.4.0.204.200", "version": "5.4.0.204.200" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.4.0-204", "" ], "package": "linux-meta", "version": "5.4.0.204.200", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Thu, 05 Dec 2024 12:37:06 +0100" }, { "cves": [], "log": [ "", " * Bump ABI 5.4.0-203", "" ], "package": "linux-meta", "version": "5.4.0.203.199", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Sat, 30 Nov 2024 20:09:02 +0100" } ], "notes": null } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-5.4.0-204", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-202.222", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.4.0-204.224", "version": "5.4.0-204.224" }, "cves": [ { "cve": "CVE-2024-50264", "url": "https://ubuntu.com/security/CVE-2024-50264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53057", "url": "https://ubuntu.com/security/CVE-2024-53057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-49967", "url": "https://ubuntu.com/security/CVE-2024-49967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-43892", "url": "https://ubuntu.com/security/CVE-2024-43892", "cve_description": "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_priority": "medium", "cve_public_date": "2024-08-26 11:15:00 UTC" }, { "cve": "CVE-2024-38553", "url": "https://ubuntu.com/security/CVE-2024-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (\"eth: sungem: remove .ndo_poll_controller to avoid deadlocks\"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2024-38597", "url": "https://ubuntu.com/security/CVE-2024-38597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2023-52821", "url": "https://ubuntu.com/security/CVE-2023-52821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2024-36952", "url": "https://ubuntu.com/security/CVE-2024-36952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-40910", "url": "https://ubuntu.com/security/CVE-2024-40910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-35963", "url": "https://ubuntu.com/security/CVE-2024-35963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35965", "url": "https://ubuntu.com/security/CVE-2024-35965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35966", "url": "https://ubuntu.com/security/CVE-2024-35966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35967", "url": "https://ubuntu.com/security/CVE-2024-35967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2021-47101", "url": "https://ubuntu.com/security/CVE-2021-47101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497", "cve_priority": "medium", "cve_public_date": "2024-03-04 18:15:00 UTC" }, { "cve": "CVE-2022-38096", "url": "https://ubuntu.com/security/CVE-2022-38096", "cve_description": "A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).", "cve_priority": "medium", "cve_public_date": "2022-09-09 15:15:00 UTC" }, { "cve": "CVE-2021-47001", "url": "https://ubuntu.com/security/CVE-2021-47001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv().", "cve_priority": "medium", "cve_public_date": "2024-02-28 09:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2091090 ], "changes": [ { "cves": [ { "cve": "CVE-2024-50264", "url": "https://ubuntu.com/security/CVE-2024-50264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53057", "url": "https://ubuntu.com/security/CVE-2024-53057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-49967", "url": "https://ubuntu.com/security/CVE-2024-49967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-43892", "url": "https://ubuntu.com/security/CVE-2024-43892", "cve_description": "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_priority": "medium", "cve_public_date": "2024-08-26 11:15:00 UTC" }, { "cve": "CVE-2024-38553", "url": "https://ubuntu.com/security/CVE-2024-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (\"eth: sungem: remove .ndo_poll_controller to avoid deadlocks\"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2024-38597", "url": "https://ubuntu.com/security/CVE-2024-38597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2023-52821", "url": "https://ubuntu.com/security/CVE-2023-52821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2024-36952", "url": "https://ubuntu.com/security/CVE-2024-36952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-40910", "url": "https://ubuntu.com/security/CVE-2024-40910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-35963", "url": "https://ubuntu.com/security/CVE-2024-35963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35965", "url": "https://ubuntu.com/security/CVE-2024-35965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35966", "url": "https://ubuntu.com/security/CVE-2024-35966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35967", "url": "https://ubuntu.com/security/CVE-2024-35967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2021-47101", "url": "https://ubuntu.com/security/CVE-2021-47101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497", "cve_priority": "medium", "cve_public_date": "2024-03-04 18:15:00 UTC" }, { "cve": "CVE-2022-38096", "url": "https://ubuntu.com/security/CVE-2022-38096", "cve_description": "A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).", "cve_priority": "medium", "cve_public_date": "2022-09-09 15:15:00 UTC" }, { "cve": "CVE-2021-47001", "url": "https://ubuntu.com/security/CVE-2021-47001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv().", "cve_priority": "medium", "cve_public_date": "2024-02-28 09:15:00 UTC" } ], "log": [ "", " * focal/linux: 5.4.0-204.224 -proposed tracker (LP: #2091090)", "", " * CVE-2024-50264", " - vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans", "", " * CVE-2024-53057", " - net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT", "", " * CVE-2024-49967", " - ext4: no need to continue when the number of entries is 1", "", " * CVE-2024-43892", " - memcg: protect concurrent access to mem_cgroup_idr", "", " * CVE-2024-38553", " - net: fec: remove .ndo_poll_controller to avoid deadlocks", "", " * CVE-2024-38597", " - eth: sungem: remove .ndo_poll_controller to avoid deadlocks", "", " * CVE-2023-52821", " - drm/panel: fix a possible null pointer dereference", "", " * CVE-2024-36952", " - scsi: lpfc: Move NPIV's transport unregistration to after resource clean up", "", " * CVE-2024-40910", " - ax25: Fix refcount imbalance on inbound connections", "", " * CVE-2024-35963", " - Bluetooth: hci_sock: Fix not validating setsockopt user input", "", " * CVE-2024-35965", " - Bluetooth: L2CAP: uninitialized variables in l2cap_sock_setsockopt()", " - Bluetooth: L2CAP: Fix not validating setsockopt user input", "", " * CVE-2024-35966", " - Bluetooth: RFCOMM: Fix not validating setsockopt user input", "", " * CVE-2024-35967", " - Bluetooth: SCO: Fix not validating setsockopt user input", "", " * CVE-2021-47101", " - net: asix: fix uninit value bugs", " - asix: fix wrong return value in asix_check_host_enable()", " - asix: fix uninit-value in asix_mdio_read()", "", " * CVE-2022-38096", " - drm/vmwgfx: Fix possible null pointer derefence with invalid contexts", "", " * CVE-2021-47001", " - xprtrdma: Fix cwnd update ordering", "" ], "package": "linux", "version": "5.4.0-204.224", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 2091090 ], "author": "Manuel Diewald ", "date": "Thu, 05 Dec 2024 12:35:34 +0100" } ], "notes": "linux-headers-5.4.0-204 version '5.4.0-204.224' (source package linux version '5.4.0-204.224') was added. linux-headers-5.4.0-204 version '5.4.0-204.224' has the same source package name, linux, as removed package linux-headers-5.4.0-202. As such we can use the source package version of the removed package, '5.4.0-202.222', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." }, { "name": "linux-headers-5.4.0-204-generic-lpae", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-202.222", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.4.0-204.224", "version": "5.4.0-204.224" }, "cves": [ { "cve": "CVE-2024-50264", "url": "https://ubuntu.com/security/CVE-2024-50264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53057", "url": "https://ubuntu.com/security/CVE-2024-53057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-49967", "url": "https://ubuntu.com/security/CVE-2024-49967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-43892", "url": "https://ubuntu.com/security/CVE-2024-43892", "cve_description": "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_priority": "medium", "cve_public_date": "2024-08-26 11:15:00 UTC" }, { "cve": "CVE-2024-38553", "url": "https://ubuntu.com/security/CVE-2024-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (\"eth: sungem: remove .ndo_poll_controller to avoid deadlocks\"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2024-38597", "url": "https://ubuntu.com/security/CVE-2024-38597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2023-52821", "url": "https://ubuntu.com/security/CVE-2023-52821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2024-36952", "url": "https://ubuntu.com/security/CVE-2024-36952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-40910", "url": "https://ubuntu.com/security/CVE-2024-40910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-35963", "url": "https://ubuntu.com/security/CVE-2024-35963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35965", "url": "https://ubuntu.com/security/CVE-2024-35965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35966", "url": "https://ubuntu.com/security/CVE-2024-35966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35967", "url": "https://ubuntu.com/security/CVE-2024-35967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2021-47101", "url": "https://ubuntu.com/security/CVE-2021-47101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497", "cve_priority": "medium", "cve_public_date": "2024-03-04 18:15:00 UTC" }, { "cve": "CVE-2022-38096", "url": "https://ubuntu.com/security/CVE-2022-38096", "cve_description": "A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).", "cve_priority": "medium", "cve_public_date": "2022-09-09 15:15:00 UTC" }, { "cve": "CVE-2021-47001", "url": "https://ubuntu.com/security/CVE-2021-47001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv().", "cve_priority": "medium", "cve_public_date": "2024-02-28 09:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2091090 ], "changes": [ { "cves": [ { "cve": "CVE-2024-50264", "url": "https://ubuntu.com/security/CVE-2024-50264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53057", "url": "https://ubuntu.com/security/CVE-2024-53057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-49967", "url": "https://ubuntu.com/security/CVE-2024-49967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-43892", "url": "https://ubuntu.com/security/CVE-2024-43892", "cve_description": "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_priority": "medium", "cve_public_date": "2024-08-26 11:15:00 UTC" }, { "cve": "CVE-2024-38553", "url": "https://ubuntu.com/security/CVE-2024-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (\"eth: sungem: remove .ndo_poll_controller to avoid deadlocks\"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2024-38597", "url": "https://ubuntu.com/security/CVE-2024-38597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2023-52821", "url": "https://ubuntu.com/security/CVE-2023-52821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2024-36952", "url": "https://ubuntu.com/security/CVE-2024-36952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-40910", "url": "https://ubuntu.com/security/CVE-2024-40910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-35963", "url": "https://ubuntu.com/security/CVE-2024-35963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35965", "url": "https://ubuntu.com/security/CVE-2024-35965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35966", "url": "https://ubuntu.com/security/CVE-2024-35966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35967", "url": "https://ubuntu.com/security/CVE-2024-35967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2021-47101", "url": "https://ubuntu.com/security/CVE-2021-47101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497", "cve_priority": "medium", "cve_public_date": "2024-03-04 18:15:00 UTC" }, { "cve": "CVE-2022-38096", "url": "https://ubuntu.com/security/CVE-2022-38096", "cve_description": "A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).", "cve_priority": "medium", "cve_public_date": "2022-09-09 15:15:00 UTC" }, { "cve": "CVE-2021-47001", "url": "https://ubuntu.com/security/CVE-2021-47001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv().", "cve_priority": "medium", "cve_public_date": "2024-02-28 09:15:00 UTC" } ], "log": [ "", " * focal/linux: 5.4.0-204.224 -proposed tracker (LP: #2091090)", "", " * CVE-2024-50264", " - vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans", "", " * CVE-2024-53057", " - net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT", "", " * CVE-2024-49967", " - ext4: no need to continue when the number of entries is 1", "", " * CVE-2024-43892", " - memcg: protect concurrent access to mem_cgroup_idr", "", " * CVE-2024-38553", " - net: fec: remove .ndo_poll_controller to avoid deadlocks", "", " * CVE-2024-38597", " - eth: sungem: remove .ndo_poll_controller to avoid deadlocks", "", " * CVE-2023-52821", " - drm/panel: fix a possible null pointer dereference", "", " * CVE-2024-36952", " - scsi: lpfc: Move NPIV's transport unregistration to after resource clean up", "", " * CVE-2024-40910", " - ax25: Fix refcount imbalance on inbound connections", "", " * CVE-2024-35963", " - Bluetooth: hci_sock: Fix not validating setsockopt user input", "", " * CVE-2024-35965", " - Bluetooth: L2CAP: uninitialized variables in l2cap_sock_setsockopt()", " - Bluetooth: L2CAP: Fix not validating setsockopt user input", "", " * CVE-2024-35966", " - Bluetooth: RFCOMM: Fix not validating setsockopt user input", "", " * CVE-2024-35967", " - Bluetooth: SCO: Fix not validating setsockopt user input", "", " * CVE-2021-47101", " - net: asix: fix uninit value bugs", " - asix: fix wrong return value in asix_check_host_enable()", " - asix: fix uninit-value in asix_mdio_read()", "", " * CVE-2022-38096", " - drm/vmwgfx: Fix possible null pointer derefence with invalid contexts", "", " * CVE-2021-47001", " - xprtrdma: Fix cwnd update ordering", "" ], "package": "linux", "version": "5.4.0-204.224", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 2091090 ], "author": "Manuel Diewald ", "date": "Thu, 05 Dec 2024 12:35:34 +0100" } ], "notes": "linux-headers-5.4.0-204-generic-lpae version '5.4.0-204.224' (source package linux version '5.4.0-204.224') was added. linux-headers-5.4.0-204-generic-lpae version '5.4.0-204.224' has the same source package name, linux, as removed package linux-headers-5.4.0-202. As such we can use the source package version of the removed package, '5.4.0-202.222', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." }, { "name": "linux-image-5.4.0-204-generic-lpae", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-202.222", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.4.0-204.224", "version": "5.4.0-204.224" }, "cves": [ { "cve": "CVE-2024-50264", "url": "https://ubuntu.com/security/CVE-2024-50264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53057", "url": "https://ubuntu.com/security/CVE-2024-53057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-49967", "url": "https://ubuntu.com/security/CVE-2024-49967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-43892", "url": "https://ubuntu.com/security/CVE-2024-43892", "cve_description": "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_priority": "medium", "cve_public_date": "2024-08-26 11:15:00 UTC" }, { "cve": "CVE-2024-38553", "url": "https://ubuntu.com/security/CVE-2024-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (\"eth: sungem: remove .ndo_poll_controller to avoid deadlocks\"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2024-38597", "url": "https://ubuntu.com/security/CVE-2024-38597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2023-52821", "url": "https://ubuntu.com/security/CVE-2023-52821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2024-36952", "url": "https://ubuntu.com/security/CVE-2024-36952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-40910", "url": "https://ubuntu.com/security/CVE-2024-40910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-35963", "url": "https://ubuntu.com/security/CVE-2024-35963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35965", "url": "https://ubuntu.com/security/CVE-2024-35965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35966", "url": "https://ubuntu.com/security/CVE-2024-35966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35967", "url": "https://ubuntu.com/security/CVE-2024-35967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2021-47101", "url": "https://ubuntu.com/security/CVE-2021-47101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497", "cve_priority": "medium", "cve_public_date": "2024-03-04 18:15:00 UTC" }, { "cve": "CVE-2022-38096", "url": "https://ubuntu.com/security/CVE-2022-38096", "cve_description": "A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).", "cve_priority": "medium", "cve_public_date": "2022-09-09 15:15:00 UTC" }, { "cve": "CVE-2021-47001", "url": "https://ubuntu.com/security/CVE-2021-47001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv().", "cve_priority": "medium", "cve_public_date": "2024-02-28 09:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2091090 ], "changes": [ { "cves": [ { "cve": "CVE-2024-50264", "url": "https://ubuntu.com/security/CVE-2024-50264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53057", "url": "https://ubuntu.com/security/CVE-2024-53057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-49967", "url": "https://ubuntu.com/security/CVE-2024-49967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-43892", "url": "https://ubuntu.com/security/CVE-2024-43892", "cve_description": "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_priority": "medium", "cve_public_date": "2024-08-26 11:15:00 UTC" }, { "cve": "CVE-2024-38553", "url": "https://ubuntu.com/security/CVE-2024-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (\"eth: sungem: remove .ndo_poll_controller to avoid deadlocks\"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2024-38597", "url": "https://ubuntu.com/security/CVE-2024-38597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2023-52821", "url": "https://ubuntu.com/security/CVE-2023-52821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2024-36952", "url": "https://ubuntu.com/security/CVE-2024-36952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-40910", "url": "https://ubuntu.com/security/CVE-2024-40910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-35963", "url": "https://ubuntu.com/security/CVE-2024-35963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35965", "url": "https://ubuntu.com/security/CVE-2024-35965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35966", "url": "https://ubuntu.com/security/CVE-2024-35966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35967", "url": "https://ubuntu.com/security/CVE-2024-35967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2021-47101", "url": "https://ubuntu.com/security/CVE-2021-47101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497", "cve_priority": "medium", "cve_public_date": "2024-03-04 18:15:00 UTC" }, { "cve": "CVE-2022-38096", "url": "https://ubuntu.com/security/CVE-2022-38096", "cve_description": "A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).", "cve_priority": "medium", "cve_public_date": "2022-09-09 15:15:00 UTC" }, { "cve": "CVE-2021-47001", "url": "https://ubuntu.com/security/CVE-2021-47001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv().", "cve_priority": "medium", "cve_public_date": "2024-02-28 09:15:00 UTC" } ], "log": [ "", " * focal/linux: 5.4.0-204.224 -proposed tracker (LP: #2091090)", "", " * CVE-2024-50264", " - vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans", "", " * CVE-2024-53057", " - net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT", "", " * CVE-2024-49967", " - ext4: no need to continue when the number of entries is 1", "", " * CVE-2024-43892", " - memcg: protect concurrent access to mem_cgroup_idr", "", " * CVE-2024-38553", " - net: fec: remove .ndo_poll_controller to avoid deadlocks", "", " * CVE-2024-38597", " - eth: sungem: remove .ndo_poll_controller to avoid deadlocks", "", " * CVE-2023-52821", " - drm/panel: fix a possible null pointer dereference", "", " * CVE-2024-36952", " - scsi: lpfc: Move NPIV's transport unregistration to after resource clean up", "", " * CVE-2024-40910", " - ax25: Fix refcount imbalance on inbound connections", "", " * CVE-2024-35963", " - Bluetooth: hci_sock: Fix not validating setsockopt user input", "", " * CVE-2024-35965", " - Bluetooth: L2CAP: uninitialized variables in l2cap_sock_setsockopt()", " - Bluetooth: L2CAP: Fix not validating setsockopt user input", "", " * CVE-2024-35966", " - Bluetooth: RFCOMM: Fix not validating setsockopt user input", "", " * CVE-2024-35967", " - Bluetooth: SCO: Fix not validating setsockopt user input", "", " * CVE-2021-47101", " - net: asix: fix uninit value bugs", " - asix: fix wrong return value in asix_check_host_enable()", " - asix: fix uninit-value in asix_mdio_read()", "", " * CVE-2022-38096", " - drm/vmwgfx: Fix possible null pointer derefence with invalid contexts", "", " * CVE-2021-47001", " - xprtrdma: Fix cwnd update ordering", "" ], "package": "linux", "version": "5.4.0-204.224", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 2091090 ], "author": "Manuel Diewald ", "date": "Thu, 05 Dec 2024 12:35:34 +0100" } ], "notes": "linux-image-5.4.0-204-generic-lpae version '5.4.0-204.224' (source package linux version '5.4.0-204.224') was added. linux-image-5.4.0-204-generic-lpae version '5.4.0-204.224' has the same source package name, linux, as removed package linux-headers-5.4.0-202. As such we can use the source package version of the removed package, '5.4.0-202.222', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." }, { "name": "linux-modules-5.4.0-204-generic-lpae", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-202.222", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.4.0-204.224", "version": "5.4.0-204.224" }, "cves": [ { "cve": "CVE-2024-50264", "url": "https://ubuntu.com/security/CVE-2024-50264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53057", "url": "https://ubuntu.com/security/CVE-2024-53057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-49967", "url": "https://ubuntu.com/security/CVE-2024-49967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-43892", "url": "https://ubuntu.com/security/CVE-2024-43892", "cve_description": "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_priority": "medium", "cve_public_date": "2024-08-26 11:15:00 UTC" }, { "cve": "CVE-2024-38553", "url": "https://ubuntu.com/security/CVE-2024-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (\"eth: sungem: remove .ndo_poll_controller to avoid deadlocks\"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2024-38597", "url": "https://ubuntu.com/security/CVE-2024-38597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2023-52821", "url": "https://ubuntu.com/security/CVE-2023-52821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2024-36952", "url": "https://ubuntu.com/security/CVE-2024-36952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-40910", "url": "https://ubuntu.com/security/CVE-2024-40910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-35963", "url": "https://ubuntu.com/security/CVE-2024-35963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35965", "url": "https://ubuntu.com/security/CVE-2024-35965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35966", "url": "https://ubuntu.com/security/CVE-2024-35966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35967", "url": "https://ubuntu.com/security/CVE-2024-35967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2021-47101", "url": "https://ubuntu.com/security/CVE-2021-47101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497", "cve_priority": "medium", "cve_public_date": "2024-03-04 18:15:00 UTC" }, { "cve": "CVE-2022-38096", "url": "https://ubuntu.com/security/CVE-2022-38096", "cve_description": "A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).", "cve_priority": "medium", "cve_public_date": "2022-09-09 15:15:00 UTC" }, { "cve": "CVE-2021-47001", "url": "https://ubuntu.com/security/CVE-2021-47001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv().", "cve_priority": "medium", "cve_public_date": "2024-02-28 09:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2091090 ], "changes": [ { "cves": [ { "cve": "CVE-2024-50264", "url": "https://ubuntu.com/security/CVE-2024-50264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53057", "url": "https://ubuntu.com/security/CVE-2024-53057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-49967", "url": "https://ubuntu.com/security/CVE-2024-49967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-43892", "url": "https://ubuntu.com/security/CVE-2024-43892", "cve_description": "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_priority": "medium", "cve_public_date": "2024-08-26 11:15:00 UTC" }, { "cve": "CVE-2024-38553", "url": "https://ubuntu.com/security/CVE-2024-38553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (\"eth: sungem: remove .ndo_poll_controller to avoid deadlocks\"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2024-38597", "url": "https://ubuntu.com/security/CVE-2024-38597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.", "cve_priority": "medium", "cve_public_date": "2024-06-19 14:15:00 UTC" }, { "cve": "CVE-2023-52821", "url": "https://ubuntu.com/security/CVE-2023-52821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.", "cve_priority": "medium", "cve_public_date": "2024-05-21 16:15:00 UTC" }, { "cve": "CVE-2024-36952", "url": "https://ubuntu.com/security/CVE-2024-36952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.", "cve_priority": "medium", "cve_public_date": "2024-05-30 16:15:00 UTC" }, { "cve": "CVE-2024-40910", "url": "https://ubuntu.com/security/CVE-2024-40910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-35963", "url": "https://ubuntu.com/security/CVE-2024-35963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35965", "url": "https://ubuntu.com/security/CVE-2024-35965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data.", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35966", "url": "https://ubuntu.com/security/CVE-2024-35966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2024-35967", "url": "https://ubuntu.com/security/CVE-2024-35967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578", "cve_priority": "medium", "cve_public_date": "2024-05-20 10:15:00 UTC" }, { "cve": "CVE-2021-47101", "url": "https://ubuntu.com/security/CVE-2021-47101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497", "cve_priority": "medium", "cve_public_date": "2024-03-04 18:15:00 UTC" }, { "cve": "CVE-2022-38096", "url": "https://ubuntu.com/security/CVE-2022-38096", "cve_description": "A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).", "cve_priority": "medium", "cve_public_date": "2022-09-09 15:15:00 UTC" }, { "cve": "CVE-2021-47001", "url": "https://ubuntu.com/security/CVE-2021-47001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv().", "cve_priority": "medium", "cve_public_date": "2024-02-28 09:15:00 UTC" } ], "log": [ "", " * focal/linux: 5.4.0-204.224 -proposed tracker (LP: #2091090)", "", " * CVE-2024-50264", " - vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans", "", " * CVE-2024-53057", " - net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT", "", " * CVE-2024-49967", " - ext4: no need to continue when the number of entries is 1", "", " * CVE-2024-43892", " - memcg: protect concurrent access to mem_cgroup_idr", "", " * CVE-2024-38553", " - net: fec: remove .ndo_poll_controller to avoid deadlocks", "", " * CVE-2024-38597", " - eth: sungem: remove .ndo_poll_controller to avoid deadlocks", "", " * CVE-2023-52821", " - drm/panel: fix a possible null pointer dereference", "", " * CVE-2024-36952", " - scsi: lpfc: Move NPIV's transport unregistration to after resource clean up", "", " * CVE-2024-40910", " - ax25: Fix refcount imbalance on inbound connections", "", " * CVE-2024-35963", " - Bluetooth: hci_sock: Fix not validating setsockopt user input", "", " * CVE-2024-35965", " - Bluetooth: L2CAP: uninitialized variables in l2cap_sock_setsockopt()", " - Bluetooth: L2CAP: Fix not validating setsockopt user input", "", " * CVE-2024-35966", " - Bluetooth: RFCOMM: Fix not validating setsockopt user input", "", " * CVE-2024-35967", " - Bluetooth: SCO: Fix not validating setsockopt user input", "", " * CVE-2021-47101", " - net: asix: fix uninit value bugs", " - asix: fix wrong return value in asix_check_host_enable()", " - asix: fix uninit-value in asix_mdio_read()", "", " * CVE-2022-38096", " - drm/vmwgfx: Fix possible null pointer derefence with invalid contexts", "", " * CVE-2021-47001", " - xprtrdma: Fix cwnd update ordering", "" ], "package": "linux", "version": "5.4.0-204.224", "urgency": "medium", "distributions": "focal", "launchpad_bugs_fixed": [ 2091090 ], "author": "Manuel Diewald ", "date": "Thu, 05 Dec 2024 12:35:34 +0100" } ], "notes": "linux-modules-5.4.0-204-generic-lpae version '5.4.0-204.224' (source package linux version '5.4.0-204.224') was added. linux-modules-5.4.0-204-generic-lpae version '5.4.0-204.224' has the same source package name, linux, as removed package linux-headers-5.4.0-202. As such we can use the source package version of the removed package, '5.4.0-202.222', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package." } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-5.4.0-202", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-202.222", "version": "5.4.0-202.222" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-headers-5.4.0-202-generic-lpae", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-202.222", "version": "5.4.0-202.222" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-image-5.4.0-202-generic-lpae", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-202.222", "version": "5.4.0-202.222" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-modules-5.4.0-202-generic-lpae", "from_version": { "source_package_name": "linux", "source_package_version": "5.4.0-202.222", "version": "5.4.0-202.222" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 20.04 focal image from daily image serial 20241212 to 20241216", "from_series": "focal", "to_series": "focal", "from_serial": "20241212", "to_serial": "20241216", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }