{ "summary": { "snap": { "added": [], "removed": [], "diff": [ "core20" ] }, "deb": { "added": [ "linux-headers-5.15.0-133", "linux-headers-5.15.0-133-generic", "linux-image-5.15.0-133-generic", "linux-modules-5.15.0-133-generic" ], "removed": [ "linux-headers-5.15.0-131", "linux-headers-5.15.0-131-generic", "linux-image-5.15.0-131-generic", "linux-modules-5.15.0-131-generic" ], "diff": [ "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-virtual" ] } }, "diff": { "deb": [ { "name": "linux-headers-generic", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.131.129", "version": "5.15.0.131.129" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.133.132", "version": "5.15.0.133.132" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-133", "" ], "package": "linux-meta", "version": "5.15.0.133.132", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 19:11:54 +0100" }, { "cves": [], "log": [ "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "5.15.0.132.131", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Wed, 15 Jan 2025 15:58:03 +0100" }, { "cves": [], "log": [ "", " * Bump ABI 5.15.0-132", "" ], "package": "linux-meta", "version": "5.15.0.132.130", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Mon, 13 Jan 2025 04:01:00 +0300" } ], "notes": null }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.131.129", "version": "5.15.0.131.129" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.133.132", "version": "5.15.0.133.132" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-133", "" ], "package": "linux-meta", "version": "5.15.0.133.132", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 19:11:54 +0100" }, { "cves": [], "log": [ "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "5.15.0.132.131", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Wed, 15 Jan 2025 15:58:03 +0100" }, { "cves": [], "log": [ "", " * Bump ABI 5.15.0-132", "" ], "package": "linux-meta", "version": "5.15.0.132.130", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Mon, 13 Jan 2025 04:01:00 +0300" } ], "notes": null }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.131.129", "version": "5.15.0.131.129" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.133.132", "version": "5.15.0.133.132" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-133", "" ], "package": "linux-meta", "version": "5.15.0.133.132", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 19:11:54 +0100" }, { "cves": [], "log": [ "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "5.15.0.132.131", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Wed, 15 Jan 2025 15:58:03 +0100" }, { "cves": [], "log": [ "", " * Bump ABI 5.15.0-132", "" ], "package": "linux-meta", "version": "5.15.0.132.130", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Mon, 13 Jan 2025 04:01:00 +0300" } ], "notes": null }, { "name": "linux-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.131.129", "version": "5.15.0.131.129" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.133.132", "version": "5.15.0.133.132" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-133", "" ], "package": "linux-meta", "version": "5.15.0.133.132", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 19:11:54 +0100" }, { "cves": [], "log": [ "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "5.15.0.132.131", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Wed, 15 Jan 2025 15:58:03 +0100" }, { "cves": [], "log": [ "", " * Bump ABI 5.15.0-132", "" ], "package": "linux-meta", "version": "5.15.0.132.130", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Mon, 13 Jan 2025 04:01:00 +0300" } ], "notes": null } ], "snap": [ { "name": "core20", "from_version": { "source_package_name": null, "source_package_version": null, "version": "2434" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": "2496" } } ] }, "added": { "deb": [ { "name": "linux-headers-5.15.0-133", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-131.141", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.15.0-133.144", "version": "5.15.0-133.144" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-41080", "url": "https://ubuntu.com/security/CVE-2024-41080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: fix possible deadlock in io_register_iowq_max_workers() The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee (\"io_uring: drop ctx->uring_lock before acquiring sqd->lock\"), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-42291", "url": "https://ubuntu.com/security/CVE-2024-42291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice.", "cve_priority": "medium", "cve_public_date": "2024-08-17 09:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2023-52913", "url": "https://ubuntu.com/security/CVE-2023-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential context UAFs gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. [tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)", "cve_priority": "medium", "cve_public_date": "2024-08-21 07:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50141", "url": "https://ubuntu.com/security/CVE-2024-50141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50142", "url": "https://ubuntu.com/security/CVE-2024-50142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a (\"xfrm: Validate address prefix lengths in the xfrm selector.\") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50103", "url": "https://ubuntu.com/security/CVE-2024-50103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50110", "url": "https://ubuntu.com/security/CVE-2024-50110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix one more kernel-infoleak in algo dumping During fuzz testing, the following issue was discovered: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Bytes 328-379 of 732 are uninitialized Memory access of size 732 starts at ffff88800e18e000 Data copied to user address 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Fixes copying of xfrm algorithms where some random data of the structure fields can end up in userspace. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space. A similar issue was resolved in the commit 8222d5910dae (\"xfrm: Zero padding when dumping algos and encap\") Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50115", "url": "https://ubuntu.com/security/CVE-2024-50115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50116", "url": "https://ubuntu.com/security/CVE-2024-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50117", "url": "https://ubuntu.com/security/CVE-2024-50117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50205", "url": "https://ubuntu.com/security/CVE-2024-50205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b (\"ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50127", "url": "https://ubuntu.com/security/CVE-2024-50127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50128", "url": "https://ubuntu.com/security/CVE-2024-50128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 (\"net: qualcomm: rmnet: fix global oob in rmnet_policy\"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of `nla_parse_nested_deprecated`, use correct size `IFLA_WWAN_MAX` here to fix this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50167", "url": "https://ubuntu.com/security/CVE-2024-50167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50168", "url": "https://ubuntu.com/security/CVE-2024-50168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50131", "url": "https://ubuntu.com/security/CVE-2024-50131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50143", "url": "https://ubuntu.com/security/CVE-2024-50143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50134", "url": "https://ubuntu.com/security/CVE-2024-50134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a \"memcpy: detected field-spanning write error\" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field \"p->data\" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50148", "url": "https://ubuntu.com/security/CVE-2024-50148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock's resource. To solve above issue just return bnep_sock_init()'s return value in bnep_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50150", "url": "https://ubuntu.com/security/CVE-2024-50150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50151", "url": "https://ubuntu.com/security/CVE-2024-50151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e \"print('a')for 1..1024\") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50153", "url": "https://ubuntu.com/security/CVE-2024-50153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50154", "url": "https://ubuntu.com/security/CVE-2024-50154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). \"\"\" We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. \"\"\" The commit 83fccfc3940c (\"inet: fix potential deadlock in reqsk_queue_unlink()\") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50171", "url": "https://ubuntu.com/security/CVE-2024-50171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50156", "url": "https://ubuntu.com/security/CVE-2024-50156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since \"dump_addr\" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print \"Registers not stored\" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`. Patchwork: https://patchwork.freedesktop.org/patch/619657/", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50208", "url": "https://ubuntu.com/security/CVE-2024-50208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50160", "url": "https://ubuntu.com/security/CVE-2024-50160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50209", "url": "https://ubuntu.com/security/CVE-2024-50209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50162", "url": "https://ubuntu.com/security/CVE-2024-50162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set. This is particularly bad since accessing ingress_ifindex, e.g. SEC(\"xdp\") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC(\"xdp/devmap\") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk(\"ifindex %i\", pkt->ingress_ifindex); return XDP_PASS; } depends on access to rxq, so a NULL pointer gets dereferenced: <1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 574.475188] #PF: supervisor read access in kernel mode <1>[ 574.475194] #PF: error_code(0x0000) - not-present page <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 <4>[ 574.475231] Workqueue: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Call Trace: <4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490 <4>[ 574.475346] ? kmem_cache_free+0x257/0x280 <4>[ 574.475357] ? exc_page_fault+0x67/0x150 <4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30 <4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475386] bq_xmit_all+0x158/0x420 <4>[ 574.475397] __dev_flush+0x30/0x90 <4>[ 574.475407] veth_poll+0x216/0x250 [veth] <4>[ 574.475421] __napi_poll+0x28/0x1c0 <4>[ 574.475430] net_rx_action+0x32d/0x3a0 <4>[ 574.475441] handle_softirqs+0xcb/0x2c0 <4>[ 574.475451] do_softirq+0x40/0x60 <4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70 <4>[ 574.475471] __dev_queue_xmit+0x268/0xe40 <4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420 <4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0 <4>[ 574.475502] ip6_finish_output2+0x2be/0x640 <4>[ 574.475512] ? nf_hook_slow+0x42/0xf0 <4>[ 574.475521] ip6_finish_output+0x194/0x300 <4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 574.475538] mld_sendpack+0x17c/0x240 <4>[ 574.475548] mld_ifc_work+0x192/0x410 <4>[ 574.475557] process_one_work+0x15d/0x380 <4>[ 574.475566] worker_thread+0x29d/0x3a0 <4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? __pfx_kthread+0x10/0x10 <4>[ 574.475606] ret_from_fork+0x31/0x50 <4>[ 574.475615] ? __pfx_kthread+0x10/0x10 <4>[ 574.475623] ret_from_fork_asm+0x1a/0x ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50163", "url": "https://ubuntu.com/security/CVE-2024-50163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-35887", "url": "https://ubuntu.com/security/CVE-2024-35887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.", "cve_priority": "low", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2024-40965", "url": "https://ubuntu.com/security/CVE-2024-40965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: lpi2c: Avoid calling clk_get_rate during transfer Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-40982", "url": "https://ubuntu.com/security/CVE-2024-40982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ssb: Fix potential NULL pointer dereference in ssb_device_uevent() The ssb_device_uevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL. To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-41066", "url": "https://ubuntu.com/security/CVE-2024-41066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] \tconsumer_index^ tx_buff == [skb=null, skb=, skb=, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-42252", "url": "https://ubuntu.com/security/CVE-2024-42252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s", "cve_priority": "medium", "cve_public_date": "2024-08-08 09:15:00 UTC" }, { "cve": "CVE-2024-53097", "url": "https://ubuntu.com/security/CVE-2024-53097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: krealloc: Fix MTE false alarm in __do_krealloc This patch addresses an issue introduced by commit 1a83a716ec233 (\"mm: krealloc: consider spare memory for __GFP_ZERO\") which causes MTE (Memory Tagging Extension) to falsely report a slab-out-of-bounds error. The problem occurs when zeroing out spare memory in __do_krealloc. The original code only considered software-based KASAN and did not account for MTE. It does not reset the KASAN tag before calling memset, leading to a mismatch between the pointer tag and the memory tag, resulting in a false positive. Example of the error: ================================================================== swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188 swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1 swapper/0: Pointer tag: [f4], memory tag: [fe] swapper/0: swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12. swapper/0: Hardware name: MT6991(ENG) (DT) swapper/0: Call trace: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c swapper/0: el1h_64_sync_handler+0x80/0xcc swapper/0: el1h_64_sync+0x68/0x6c swapper/0: __memset+0x84/0x188 swapper/0: btf_populate_kfunc_set+0x280/0x3d8 swapper/0: __register_btf_kfunc_id_set+0x43c/0x468 swapper/0: register_btf_kfunc_id_set+0x48/0x60 swapper/0: register_nf_nat_bpf+0x1c/0x40 swapper/0: nf_nat_init+0xc0/0x128 swapper/0: do_one_initcall+0x184/0x464 swapper/0: do_initcall_level+0xdc/0x1b0 swapper/0: do_initcalls+0x70/0xc0 swapper/0: do_basic_setup+0x1c/0x28 swapper/0: kernel_init_freeable+0x144/0x1b8 swapper/0: kernel_init+0x20/0x1a8 swapper/0: ret_from_fork+0x10/0x20 ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093735, 1786013, 2093146, 2089541, 2089541, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089699, 2089373, 2086606, 2087853, 2088231 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "5.15.0-133.144", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:33 +0100" }, { "cves": [ { "cve": "CVE-2024-41080", "url": "https://ubuntu.com/security/CVE-2024-41080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: fix possible deadlock in io_register_iowq_max_workers() The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee (\"io_uring: drop ctx->uring_lock before acquiring sqd->lock\"), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-42291", "url": "https://ubuntu.com/security/CVE-2024-42291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice.", "cve_priority": "medium", "cve_public_date": "2024-08-17 09:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2023-52913", "url": "https://ubuntu.com/security/CVE-2023-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential context UAFs gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. [tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)", "cve_priority": "medium", "cve_public_date": "2024-08-21 07:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50141", "url": "https://ubuntu.com/security/CVE-2024-50141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50142", "url": "https://ubuntu.com/security/CVE-2024-50142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a (\"xfrm: Validate address prefix lengths in the xfrm selector.\") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50103", "url": "https://ubuntu.com/security/CVE-2024-50103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50110", "url": "https://ubuntu.com/security/CVE-2024-50110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix one more kernel-infoleak in algo dumping During fuzz testing, the following issue was discovered: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Bytes 328-379 of 732 are uninitialized Memory access of size 732 starts at ffff88800e18e000 Data copied to user address 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Fixes copying of xfrm algorithms where some random data of the structure fields can end up in userspace. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space. A similar issue was resolved in the commit 8222d5910dae (\"xfrm: Zero padding when dumping algos and encap\") Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50115", "url": "https://ubuntu.com/security/CVE-2024-50115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50116", "url": "https://ubuntu.com/security/CVE-2024-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50117", "url": "https://ubuntu.com/security/CVE-2024-50117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50205", "url": "https://ubuntu.com/security/CVE-2024-50205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b (\"ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50127", "url": "https://ubuntu.com/security/CVE-2024-50127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50128", "url": "https://ubuntu.com/security/CVE-2024-50128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 (\"net: qualcomm: rmnet: fix global oob in rmnet_policy\"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of `nla_parse_nested_deprecated`, use correct size `IFLA_WWAN_MAX` here to fix this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50167", "url": "https://ubuntu.com/security/CVE-2024-50167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50168", "url": "https://ubuntu.com/security/CVE-2024-50168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50131", "url": "https://ubuntu.com/security/CVE-2024-50131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50143", "url": "https://ubuntu.com/security/CVE-2024-50143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50134", "url": "https://ubuntu.com/security/CVE-2024-50134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a \"memcpy: detected field-spanning write error\" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field \"p->data\" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50148", "url": "https://ubuntu.com/security/CVE-2024-50148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock's resource. To solve above issue just return bnep_sock_init()'s return value in bnep_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50150", "url": "https://ubuntu.com/security/CVE-2024-50150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50151", "url": "https://ubuntu.com/security/CVE-2024-50151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e \"print('a')for 1..1024\") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50153", "url": "https://ubuntu.com/security/CVE-2024-50153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50154", "url": "https://ubuntu.com/security/CVE-2024-50154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). \"\"\" We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. \"\"\" The commit 83fccfc3940c (\"inet: fix potential deadlock in reqsk_queue_unlink()\") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50171", "url": "https://ubuntu.com/security/CVE-2024-50171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50156", "url": "https://ubuntu.com/security/CVE-2024-50156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since \"dump_addr\" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print \"Registers not stored\" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`. Patchwork: https://patchwork.freedesktop.org/patch/619657/", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50208", "url": "https://ubuntu.com/security/CVE-2024-50208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50160", "url": "https://ubuntu.com/security/CVE-2024-50160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50209", "url": "https://ubuntu.com/security/CVE-2024-50209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50162", "url": "https://ubuntu.com/security/CVE-2024-50162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set. This is particularly bad since accessing ingress_ifindex, e.g. SEC(\"xdp\") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC(\"xdp/devmap\") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk(\"ifindex %i\", pkt->ingress_ifindex); return XDP_PASS; } depends on access to rxq, so a NULL pointer gets dereferenced: <1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 574.475188] #PF: supervisor read access in kernel mode <1>[ 574.475194] #PF: error_code(0x0000) - not-present page <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 <4>[ 574.475231] Workqueue: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Call Trace: <4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490 <4>[ 574.475346] ? kmem_cache_free+0x257/0x280 <4>[ 574.475357] ? exc_page_fault+0x67/0x150 <4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30 <4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475386] bq_xmit_all+0x158/0x420 <4>[ 574.475397] __dev_flush+0x30/0x90 <4>[ 574.475407] veth_poll+0x216/0x250 [veth] <4>[ 574.475421] __napi_poll+0x28/0x1c0 <4>[ 574.475430] net_rx_action+0x32d/0x3a0 <4>[ 574.475441] handle_softirqs+0xcb/0x2c0 <4>[ 574.475451] do_softirq+0x40/0x60 <4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70 <4>[ 574.475471] __dev_queue_xmit+0x268/0xe40 <4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420 <4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0 <4>[ 574.475502] ip6_finish_output2+0x2be/0x640 <4>[ 574.475512] ? nf_hook_slow+0x42/0xf0 <4>[ 574.475521] ip6_finish_output+0x194/0x300 <4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 574.475538] mld_sendpack+0x17c/0x240 <4>[ 574.475548] mld_ifc_work+0x192/0x410 <4>[ 574.475557] process_one_work+0x15d/0x380 <4>[ 574.475566] worker_thread+0x29d/0x3a0 <4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? __pfx_kthread+0x10/0x10 <4>[ 574.475606] ret_from_fork+0x31/0x50 <4>[ 574.475615] ? __pfx_kthread+0x10/0x10 <4>[ 574.475623] ret_from_fork_asm+0x1a/0x ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50163", "url": "https://ubuntu.com/security/CVE-2024-50163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-35887", "url": "https://ubuntu.com/security/CVE-2024-35887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.", "cve_priority": "low", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2024-40965", "url": "https://ubuntu.com/security/CVE-2024-40965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: lpi2c: Avoid calling clk_get_rate during transfer Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-40982", "url": "https://ubuntu.com/security/CVE-2024-40982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ssb: Fix potential NULL pointer dereference in ssb_device_uevent() The ssb_device_uevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL. To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-41066", "url": "https://ubuntu.com/security/CVE-2024-41066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] \tconsumer_index^ tx_buff == [skb=null, skb=, skb=, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-42252", "url": "https://ubuntu.com/security/CVE-2024-42252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s", "cve_priority": "medium", "cve_public_date": "2024-08-08 09:15:00 UTC" }, { "cve": "CVE-2024-53097", "url": "https://ubuntu.com/security/CVE-2024-53097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: krealloc: Fix MTE false alarm in __do_krealloc This patch addresses an issue introduced by commit 1a83a716ec233 (\"mm: krealloc: consider spare memory for __GFP_ZERO\") which causes MTE (Memory Tagging Extension) to falsely report a slab-out-of-bounds error. The problem occurs when zeroing out spare memory in __do_krealloc. The original code only considered software-based KASAN and did not account for MTE. It does not reset the KASAN tag before calling memset, leading to a mismatch between the pointer tag and the memory tag, resulting in a false positive. Example of the error: ================================================================== swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188 swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1 swapper/0: Pointer tag: [f4], memory tag: [fe] swapper/0: swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12. swapper/0: Hardware name: MT6991(ENG) (DT) swapper/0: Call trace: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c swapper/0: el1h_64_sync_handler+0x80/0xcc swapper/0: el1h_64_sync+0x68/0x6c swapper/0: __memset+0x84/0x188 swapper/0: btf_populate_kfunc_set+0x280/0x3d8 swapper/0: __register_btf_kfunc_id_set+0x43c/0x468 swapper/0: register_btf_kfunc_id_set+0x48/0x60 swapper/0: register_nf_nat_bpf+0x1c/0x40 swapper/0: nf_nat_init+0xc0/0x128 swapper/0: do_one_initcall+0x184/0x464 swapper/0: do_initcall_level+0xdc/0x1b0 swapper/0: do_initcalls+0x70/0xc0 swapper/0: do_basic_setup+0x1c/0x28 swapper/0: kernel_init_freeable+0x144/0x1b8 swapper/0: kernel_init+0x20/0x1a8 swapper/0: ret_from_fork+0x10/0x20 ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" } ], "log": [ "", " * jammy/linux: 5.15.0-132.143 -proposed tracker (LP: #2093735)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - kvm: x86: Fix xstate_required_size() to follow XSTATE alignment rule", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * Jammy update: v5.15.173 upstream stable release (LP: #2089541)", " - 9p: Avoid creating multiple slab caches with the same name", " - irqchip/ocelot: Fix trigger register address", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: marvell/cesa - Disable hash algorithms", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - powerpc/powernv: Free name on error in opal_event_init()", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - md/raid10: improve code of mrdev in raid10_sync_request", " - mm/memory: add non-anonymous page check in the copy_present_page()", " - udf: Allocate name buffer in directory iterator on heap", " - udf: Avoid directory type conversion failure due to ENOMEM", " - 9p: fix slab cache name creation for real", " - Linux 5.15.173", "", " * Jammy update: v5.15.173 upstream stable release (LP: #2089541) //", " CVE-2024-41080", " - io_uring: fix possible deadlock in io_register_iowq_max_workers()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Add a tracepoint to show the results of nfs_set_cache_invalid()", " - NFSv3: handle out-of-order write replies.", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - can: c_can: fix {rx,tx}_errors statistics", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - io_uring: rename kiocb_end_write() local helper", " - fs: create kiocb_{start,end}_write() helpers", " - io_uring: use kiocb_{start,end}_write() helpers", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - ALSA: usb-audio: Support jack detection on Dell dock", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ALSA: usb-audio: Add endianness annotations", " - Linux 5.15.172", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-42291", " - ice: Add a per-VF limit on number of FDIR filters", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405)", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - ACPI: PRM: Remove unnecessary blank lines", " - ACPI: PRM: Change handler_addr type to void pointer", " - cgroup: Fix potential overflow issue when checking max_depth", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - mac80211: do drv_reconfig_complete() before restarting all", " - mac80211: Add support to trigger sta disconnect on hardware restart", " - wifi: iwlwifi: mvm: disconnect station vifs if recovery failed", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - gtp: allow -1 to be specified as file description from userspace", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - iio: light: veml6030: fix microlux value calculation", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - mm/page_alloc: call check_new_pages() while zone spinlock is not held", " - mm/page_alloc: fix tracepoint mm_page_alloc_zone_locked()", " - mm/page_alloc: split out buddy removal code from rmqueue into separate", " helper", " - mm/page_alloc: rename ALLOC_HIGH to ALLOC_MIN_RESERVE", " - mm/page_alloc: treat RT tasks similar to __GFP_HIGH", " - mm/page_alloc: explicitly record high-order atomic allocations in", " alloc_flags", " - mm/page_alloc: explicitly define what alloc flags deplete min reserves", " - mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations", " accesses reserves", " - Revert \"drm/mipi-dsi: Set the fwnode for mipi_dsi_device\"", " - vt: prevent kernel-infoleak in con_font_get()", " - mac80211: always have ieee80211_sta_restart()", " - Linux 5.15.171", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2023-52913", " - drm/i915: Fix potential context UAFs", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50141", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272)", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - ipv4: give an IPv4 dev to blackhole_netdev", " - RDMA/bnxt_re: Return more meaningful error", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - net: usb: usbnet: fix race in probe failure", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - macsec: don't increment counters for an unrelated SA", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - genetlink: hold RCU in genlmsg_mcast()", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - arm64:uprobe fix the uprobe SWBP_INSN in big-endian", " - KVM: s390: gaccess: Check if guest address is in memslot", " - usb: gadget: Add function wakeup support", " - XHCI: Separate PORT and CAPs macros into dedicated file", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - platform/x86: dell-wmi: Ignore suspend notifications", " - arm64/uprobes: change the uprobe_opcode_t typedef to fix the sparse warning", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - platform/x86: dell-sysman: add support for alienware products", " - jfs: Fix sanity check in dbMount", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - net: plip: fix break; causing plip to never transmit", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - net: usb: usbnet: fix name regression", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - ALSA: hda/realtek: Update default depop procedure", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - selinux: improve error checking in sel_write_load()", " - net: phy: dp83822: Fix reset pin definitions", " - Linux 5.15.170", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50142", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50103", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50110", " - xfrm: fix one more kernel-infoleak in algo dumping", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50115", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50116", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50117", " - drm/amd: Guard against bad data for ATIF ACPI method", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50205", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50127", " - net: sched: fix use-after-free in taprio_change()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50128", " - net: wwan: fix global oob in wwan_rtnl_policy", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50167", " - be2net: fix potential memory leak in be_xmit()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50168", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50131", " - tracing: Consider the NULL character when validating the event length", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50143", " - udf: fix uninit-value use in udf_get_fileshortad", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50134", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50148", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50150", " - usb: typec: altmode should keep reference to parent", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50151", " - smb: client: fix OOBs when building SMB2_IOCTL request", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50153", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50154", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50171", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50156", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50208", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50160", " - ALSA: hda/cs8409: Fix possible NULL dereference", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50209", " - RDMA/bnxt_re: Add a check for memory allocation", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50162", " - bpf: devmap: provide rxq after redirect", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50163", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", "", " * kernel:nft \"Could not process rule: Device or resource busy\" on unreferenced", " chain (LP: #2089699)", " - SAUCE: netfilter: nf_tables: Fix EBUSY on deleting unreferenced chain", "", " * WARN in trc_wait_for_one_reader about failed IPIs (LP: #2089373)", " - SAUCE: rcu-tasks: fix mismerge in trc_inspect_reader", " - rcu-tasks: Idle tasks on offline CPUs are in quiescent states", "", " * CVE-2024-35887", " - ax25: fix use-after-free bugs caused by ax25_ds_del_timer", "", " * CVE-2024-40965", " - clk: Add a devm variant of clk_rate_exclusive_get()", " - clk: Provide !COMMON_CLK dummy for devm_clk_rate_exclusive_get()", " - i2c: lpi2c: Avoid calling clk_get_rate during transfer", "", " * CVE-2024-40982", " - ssb: Fix potential NULL pointer dereference in ssb_device_uevent()", "", " * CVE-2024-41066", " - ibmvnic: Add tx check to prevent skb leak", "", " * CVE-2024-42252", " - closures: Change BUG_ON() to WARN_ON()", "", " * CVE-2024-53097", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Jammy update: v5.15.169 upstream stable release (LP: #2088231)", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - udf: New directory iteration code", " - udf: Convert udf_expand_dir_adinicb() to new directory iteration", " - udf: Move udf_expand_dir_adinicb() to its callsite", " - udf: Implement searching for directory entry using new iteration code", " - udf: Provide function to mark entry as deleted using new directory iteration", " code", " - udf: Convert udf_rename() to new directory iteration code", " - udf: Convert udf_readdir() to new directory iteration", " - udf: Convert udf_lookup() to use new directory iteration code", " - udf: Convert udf_get_parent() to new directory iteration code", " - udf: Convert empty_dir() to new directory iteration code", " - udf: Convert udf_rmdir() to new directory iteration code", " - udf: Convert udf_unlink() to new directory iteration code", " - udf: Implement adding of dir entries using new iteration code", " - udf: Convert udf_add_nondir() to new directory iteration", " - udf: Convert udf_mkdir() to new directory iteration code", " - udf: Convert udf_link() to new directory iteration code", " - udf: Remove old directory iteration code", " - udf: Handle error when expanding directory", " - udf: Don't return bh from udf_expand_dir_adinicb()", " - udf: Fix bogus checksum computation in udf_rename()", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: add missing static descriptor and inline keyword", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", " - arm64: probes: Remove broken LDR (literal) uprobe support", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1", " - fat: fix uninitialized variable", " - mm/swapfile: skip HugeTLB pages for unuse_vma", " - secretmem: disable memfd_secret() if arch cannot set direct map", " - dm-crypt, dm-verity: disable tasklets", " - KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()", " - drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - io_uring/sqpoll: do not put cpumask on stack", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", " - io_uring/sqpoll: close race on waiting for sqring entries", " - drm/radeon: Fix encoder->possible_clones", " - drm/vmwgfx: Handle surface check failure correctly", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: veml6030: fix IIO device retrieval from embedded device", " - iio: light: opt3001: add missing full-scale range value", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - parport: Proper fix for array out-of-bounds access", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/apic: Always explicitly disarm TSC-deadline timer", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", " - pinctrl: ocelot: fix system hang on level based interrupts", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", " - mptcp: track and update contiguous data status", " - mptcp: handle consistently DSS corruption", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - nilfs2: propagate directory read errors from nilfs_find_entry()", " - powerpc/mm: Always update max/min_low_pfn in mem_topology_setup()", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 5.15.169", "" ], "package": "linux", "version": "5.15.0-132.143", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2093735, 1786013, 2093146, 2089541, 2089541, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089699, 2089373, 2086606, 2087853, 2088231 ], "author": "Stefan Bader ", "date": "Wed, 15 Jan 2025 15:52:39 +0100" } ], "notes": "linux-headers-5.15.0-133 version '5.15.0-133.144' (source package linux version '5.15.0-133.144') was added. linux-headers-5.15.0-133 version '5.15.0-133.144' has the same source package name, linux, as removed package linux-headers-5.15.0-131. As such we can use the source package version of the removed package, '5.15.0-131.141', 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.15.0-133-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-131.141", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.15.0-133.144", "version": "5.15.0-133.144" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-41080", "url": "https://ubuntu.com/security/CVE-2024-41080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: fix possible deadlock in io_register_iowq_max_workers() The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee (\"io_uring: drop ctx->uring_lock before acquiring sqd->lock\"), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-42291", "url": "https://ubuntu.com/security/CVE-2024-42291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice.", "cve_priority": "medium", "cve_public_date": "2024-08-17 09:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2023-52913", "url": "https://ubuntu.com/security/CVE-2023-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential context UAFs gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. [tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)", "cve_priority": "medium", "cve_public_date": "2024-08-21 07:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50141", "url": "https://ubuntu.com/security/CVE-2024-50141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50142", "url": "https://ubuntu.com/security/CVE-2024-50142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a (\"xfrm: Validate address prefix lengths in the xfrm selector.\") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50103", "url": "https://ubuntu.com/security/CVE-2024-50103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50110", "url": "https://ubuntu.com/security/CVE-2024-50110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix one more kernel-infoleak in algo dumping During fuzz testing, the following issue was discovered: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Bytes 328-379 of 732 are uninitialized Memory access of size 732 starts at ffff88800e18e000 Data copied to user address 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Fixes copying of xfrm algorithms where some random data of the structure fields can end up in userspace. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space. A similar issue was resolved in the commit 8222d5910dae (\"xfrm: Zero padding when dumping algos and encap\") Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50115", "url": "https://ubuntu.com/security/CVE-2024-50115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50116", "url": "https://ubuntu.com/security/CVE-2024-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50117", "url": "https://ubuntu.com/security/CVE-2024-50117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50205", "url": "https://ubuntu.com/security/CVE-2024-50205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b (\"ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50127", "url": "https://ubuntu.com/security/CVE-2024-50127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50128", "url": "https://ubuntu.com/security/CVE-2024-50128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 (\"net: qualcomm: rmnet: fix global oob in rmnet_policy\"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of `nla_parse_nested_deprecated`, use correct size `IFLA_WWAN_MAX` here to fix this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50167", "url": "https://ubuntu.com/security/CVE-2024-50167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50168", "url": "https://ubuntu.com/security/CVE-2024-50168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50131", "url": "https://ubuntu.com/security/CVE-2024-50131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50143", "url": "https://ubuntu.com/security/CVE-2024-50143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50134", "url": "https://ubuntu.com/security/CVE-2024-50134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a \"memcpy: detected field-spanning write error\" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field \"p->data\" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50148", "url": "https://ubuntu.com/security/CVE-2024-50148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock's resource. To solve above issue just return bnep_sock_init()'s return value in bnep_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50150", "url": "https://ubuntu.com/security/CVE-2024-50150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50151", "url": "https://ubuntu.com/security/CVE-2024-50151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e \"print('a')for 1..1024\") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50153", "url": "https://ubuntu.com/security/CVE-2024-50153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50154", "url": "https://ubuntu.com/security/CVE-2024-50154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). \"\"\" We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. \"\"\" The commit 83fccfc3940c (\"inet: fix potential deadlock in reqsk_queue_unlink()\") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50171", "url": "https://ubuntu.com/security/CVE-2024-50171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50156", "url": "https://ubuntu.com/security/CVE-2024-50156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since \"dump_addr\" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print \"Registers not stored\" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`. Patchwork: https://patchwork.freedesktop.org/patch/619657/", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50208", "url": "https://ubuntu.com/security/CVE-2024-50208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50160", "url": "https://ubuntu.com/security/CVE-2024-50160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50209", "url": "https://ubuntu.com/security/CVE-2024-50209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50162", "url": "https://ubuntu.com/security/CVE-2024-50162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set. This is particularly bad since accessing ingress_ifindex, e.g. SEC(\"xdp\") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC(\"xdp/devmap\") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk(\"ifindex %i\", pkt->ingress_ifindex); return XDP_PASS; } depends on access to rxq, so a NULL pointer gets dereferenced: <1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 574.475188] #PF: supervisor read access in kernel mode <1>[ 574.475194] #PF: error_code(0x0000) - not-present page <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 <4>[ 574.475231] Workqueue: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Call Trace: <4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490 <4>[ 574.475346] ? kmem_cache_free+0x257/0x280 <4>[ 574.475357] ? exc_page_fault+0x67/0x150 <4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30 <4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475386] bq_xmit_all+0x158/0x420 <4>[ 574.475397] __dev_flush+0x30/0x90 <4>[ 574.475407] veth_poll+0x216/0x250 [veth] <4>[ 574.475421] __napi_poll+0x28/0x1c0 <4>[ 574.475430] net_rx_action+0x32d/0x3a0 <4>[ 574.475441] handle_softirqs+0xcb/0x2c0 <4>[ 574.475451] do_softirq+0x40/0x60 <4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70 <4>[ 574.475471] __dev_queue_xmit+0x268/0xe40 <4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420 <4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0 <4>[ 574.475502] ip6_finish_output2+0x2be/0x640 <4>[ 574.475512] ? nf_hook_slow+0x42/0xf0 <4>[ 574.475521] ip6_finish_output+0x194/0x300 <4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 574.475538] mld_sendpack+0x17c/0x240 <4>[ 574.475548] mld_ifc_work+0x192/0x410 <4>[ 574.475557] process_one_work+0x15d/0x380 <4>[ 574.475566] worker_thread+0x29d/0x3a0 <4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? __pfx_kthread+0x10/0x10 <4>[ 574.475606] ret_from_fork+0x31/0x50 <4>[ 574.475615] ? __pfx_kthread+0x10/0x10 <4>[ 574.475623] ret_from_fork_asm+0x1a/0x ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50163", "url": "https://ubuntu.com/security/CVE-2024-50163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-35887", "url": "https://ubuntu.com/security/CVE-2024-35887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.", "cve_priority": "low", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2024-40965", "url": "https://ubuntu.com/security/CVE-2024-40965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: lpi2c: Avoid calling clk_get_rate during transfer Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-40982", "url": "https://ubuntu.com/security/CVE-2024-40982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ssb: Fix potential NULL pointer dereference in ssb_device_uevent() The ssb_device_uevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL. To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-41066", "url": "https://ubuntu.com/security/CVE-2024-41066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] \tconsumer_index^ tx_buff == [skb=null, skb=, skb=, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-42252", "url": "https://ubuntu.com/security/CVE-2024-42252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s", "cve_priority": "medium", "cve_public_date": "2024-08-08 09:15:00 UTC" }, { "cve": "CVE-2024-53097", "url": "https://ubuntu.com/security/CVE-2024-53097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: krealloc: Fix MTE false alarm in __do_krealloc This patch addresses an issue introduced by commit 1a83a716ec233 (\"mm: krealloc: consider spare memory for __GFP_ZERO\") which causes MTE (Memory Tagging Extension) to falsely report a slab-out-of-bounds error. The problem occurs when zeroing out spare memory in __do_krealloc. The original code only considered software-based KASAN and did not account for MTE. It does not reset the KASAN tag before calling memset, leading to a mismatch between the pointer tag and the memory tag, resulting in a false positive. Example of the error: ================================================================== swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188 swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1 swapper/0: Pointer tag: [f4], memory tag: [fe] swapper/0: swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12. swapper/0: Hardware name: MT6991(ENG) (DT) swapper/0: Call trace: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c swapper/0: el1h_64_sync_handler+0x80/0xcc swapper/0: el1h_64_sync+0x68/0x6c swapper/0: __memset+0x84/0x188 swapper/0: btf_populate_kfunc_set+0x280/0x3d8 swapper/0: __register_btf_kfunc_id_set+0x43c/0x468 swapper/0: register_btf_kfunc_id_set+0x48/0x60 swapper/0: register_nf_nat_bpf+0x1c/0x40 swapper/0: nf_nat_init+0xc0/0x128 swapper/0: do_one_initcall+0x184/0x464 swapper/0: do_initcall_level+0xdc/0x1b0 swapper/0: do_initcalls+0x70/0xc0 swapper/0: do_basic_setup+0x1c/0x28 swapper/0: kernel_init_freeable+0x144/0x1b8 swapper/0: kernel_init+0x20/0x1a8 swapper/0: ret_from_fork+0x10/0x20 ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093735, 1786013, 2093146, 2089541, 2089541, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089699, 2089373, 2086606, 2087853, 2088231 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "5.15.0-133.144", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:33 +0100" }, { "cves": [ { "cve": "CVE-2024-41080", "url": "https://ubuntu.com/security/CVE-2024-41080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: fix possible deadlock in io_register_iowq_max_workers() The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee (\"io_uring: drop ctx->uring_lock before acquiring sqd->lock\"), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-42291", "url": "https://ubuntu.com/security/CVE-2024-42291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice.", "cve_priority": "medium", "cve_public_date": "2024-08-17 09:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2023-52913", "url": "https://ubuntu.com/security/CVE-2023-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential context UAFs gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. [tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)", "cve_priority": "medium", "cve_public_date": "2024-08-21 07:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50141", "url": "https://ubuntu.com/security/CVE-2024-50141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50142", "url": "https://ubuntu.com/security/CVE-2024-50142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a (\"xfrm: Validate address prefix lengths in the xfrm selector.\") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50103", "url": "https://ubuntu.com/security/CVE-2024-50103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50110", "url": "https://ubuntu.com/security/CVE-2024-50110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix one more kernel-infoleak in algo dumping During fuzz testing, the following issue was discovered: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Bytes 328-379 of 732 are uninitialized Memory access of size 732 starts at ffff88800e18e000 Data copied to user address 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Fixes copying of xfrm algorithms where some random data of the structure fields can end up in userspace. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space. A similar issue was resolved in the commit 8222d5910dae (\"xfrm: Zero padding when dumping algos and encap\") Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50115", "url": "https://ubuntu.com/security/CVE-2024-50115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50116", "url": "https://ubuntu.com/security/CVE-2024-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50117", "url": "https://ubuntu.com/security/CVE-2024-50117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50205", "url": "https://ubuntu.com/security/CVE-2024-50205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b (\"ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50127", "url": "https://ubuntu.com/security/CVE-2024-50127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50128", "url": "https://ubuntu.com/security/CVE-2024-50128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 (\"net: qualcomm: rmnet: fix global oob in rmnet_policy\"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of `nla_parse_nested_deprecated`, use correct size `IFLA_WWAN_MAX` here to fix this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50167", "url": "https://ubuntu.com/security/CVE-2024-50167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50168", "url": "https://ubuntu.com/security/CVE-2024-50168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50131", "url": "https://ubuntu.com/security/CVE-2024-50131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50143", "url": "https://ubuntu.com/security/CVE-2024-50143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50134", "url": "https://ubuntu.com/security/CVE-2024-50134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a \"memcpy: detected field-spanning write error\" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field \"p->data\" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50148", "url": "https://ubuntu.com/security/CVE-2024-50148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock's resource. To solve above issue just return bnep_sock_init()'s return value in bnep_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50150", "url": "https://ubuntu.com/security/CVE-2024-50150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50151", "url": "https://ubuntu.com/security/CVE-2024-50151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e \"print('a')for 1..1024\") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50153", "url": "https://ubuntu.com/security/CVE-2024-50153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50154", "url": "https://ubuntu.com/security/CVE-2024-50154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). \"\"\" We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. \"\"\" The commit 83fccfc3940c (\"inet: fix potential deadlock in reqsk_queue_unlink()\") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50171", "url": "https://ubuntu.com/security/CVE-2024-50171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50156", "url": "https://ubuntu.com/security/CVE-2024-50156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since \"dump_addr\" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print \"Registers not stored\" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`. Patchwork: https://patchwork.freedesktop.org/patch/619657/", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50208", "url": "https://ubuntu.com/security/CVE-2024-50208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50160", "url": "https://ubuntu.com/security/CVE-2024-50160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50209", "url": "https://ubuntu.com/security/CVE-2024-50209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50162", "url": "https://ubuntu.com/security/CVE-2024-50162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set. This is particularly bad since accessing ingress_ifindex, e.g. SEC(\"xdp\") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC(\"xdp/devmap\") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk(\"ifindex %i\", pkt->ingress_ifindex); return XDP_PASS; } depends on access to rxq, so a NULL pointer gets dereferenced: <1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 574.475188] #PF: supervisor read access in kernel mode <1>[ 574.475194] #PF: error_code(0x0000) - not-present page <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 <4>[ 574.475231] Workqueue: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Call Trace: <4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490 <4>[ 574.475346] ? kmem_cache_free+0x257/0x280 <4>[ 574.475357] ? exc_page_fault+0x67/0x150 <4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30 <4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475386] bq_xmit_all+0x158/0x420 <4>[ 574.475397] __dev_flush+0x30/0x90 <4>[ 574.475407] veth_poll+0x216/0x250 [veth] <4>[ 574.475421] __napi_poll+0x28/0x1c0 <4>[ 574.475430] net_rx_action+0x32d/0x3a0 <4>[ 574.475441] handle_softirqs+0xcb/0x2c0 <4>[ 574.475451] do_softirq+0x40/0x60 <4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70 <4>[ 574.475471] __dev_queue_xmit+0x268/0xe40 <4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420 <4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0 <4>[ 574.475502] ip6_finish_output2+0x2be/0x640 <4>[ 574.475512] ? nf_hook_slow+0x42/0xf0 <4>[ 574.475521] ip6_finish_output+0x194/0x300 <4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 574.475538] mld_sendpack+0x17c/0x240 <4>[ 574.475548] mld_ifc_work+0x192/0x410 <4>[ 574.475557] process_one_work+0x15d/0x380 <4>[ 574.475566] worker_thread+0x29d/0x3a0 <4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? __pfx_kthread+0x10/0x10 <4>[ 574.475606] ret_from_fork+0x31/0x50 <4>[ 574.475615] ? __pfx_kthread+0x10/0x10 <4>[ 574.475623] ret_from_fork_asm+0x1a/0x ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50163", "url": "https://ubuntu.com/security/CVE-2024-50163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-35887", "url": "https://ubuntu.com/security/CVE-2024-35887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.", "cve_priority": "low", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2024-40965", "url": "https://ubuntu.com/security/CVE-2024-40965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: lpi2c: Avoid calling clk_get_rate during transfer Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-40982", "url": "https://ubuntu.com/security/CVE-2024-40982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ssb: Fix potential NULL pointer dereference in ssb_device_uevent() The ssb_device_uevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL. To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-41066", "url": "https://ubuntu.com/security/CVE-2024-41066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] \tconsumer_index^ tx_buff == [skb=null, skb=, skb=, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-42252", "url": "https://ubuntu.com/security/CVE-2024-42252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s", "cve_priority": "medium", "cve_public_date": "2024-08-08 09:15:00 UTC" }, { "cve": "CVE-2024-53097", "url": "https://ubuntu.com/security/CVE-2024-53097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: krealloc: Fix MTE false alarm in __do_krealloc This patch addresses an issue introduced by commit 1a83a716ec233 (\"mm: krealloc: consider spare memory for __GFP_ZERO\") which causes MTE (Memory Tagging Extension) to falsely report a slab-out-of-bounds error. The problem occurs when zeroing out spare memory in __do_krealloc. The original code only considered software-based KASAN and did not account for MTE. It does not reset the KASAN tag before calling memset, leading to a mismatch between the pointer tag and the memory tag, resulting in a false positive. Example of the error: ================================================================== swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188 swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1 swapper/0: Pointer tag: [f4], memory tag: [fe] swapper/0: swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12. swapper/0: Hardware name: MT6991(ENG) (DT) swapper/0: Call trace: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c swapper/0: el1h_64_sync_handler+0x80/0xcc swapper/0: el1h_64_sync+0x68/0x6c swapper/0: __memset+0x84/0x188 swapper/0: btf_populate_kfunc_set+0x280/0x3d8 swapper/0: __register_btf_kfunc_id_set+0x43c/0x468 swapper/0: register_btf_kfunc_id_set+0x48/0x60 swapper/0: register_nf_nat_bpf+0x1c/0x40 swapper/0: nf_nat_init+0xc0/0x128 swapper/0: do_one_initcall+0x184/0x464 swapper/0: do_initcall_level+0xdc/0x1b0 swapper/0: do_initcalls+0x70/0xc0 swapper/0: do_basic_setup+0x1c/0x28 swapper/0: kernel_init_freeable+0x144/0x1b8 swapper/0: kernel_init+0x20/0x1a8 swapper/0: ret_from_fork+0x10/0x20 ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" } ], "log": [ "", " * jammy/linux: 5.15.0-132.143 -proposed tracker (LP: #2093735)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - kvm: x86: Fix xstate_required_size() to follow XSTATE alignment rule", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * Jammy update: v5.15.173 upstream stable release (LP: #2089541)", " - 9p: Avoid creating multiple slab caches with the same name", " - irqchip/ocelot: Fix trigger register address", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: marvell/cesa - Disable hash algorithms", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - powerpc/powernv: Free name on error in opal_event_init()", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - md/raid10: improve code of mrdev in raid10_sync_request", " - mm/memory: add non-anonymous page check in the copy_present_page()", " - udf: Allocate name buffer in directory iterator on heap", " - udf: Avoid directory type conversion failure due to ENOMEM", " - 9p: fix slab cache name creation for real", " - Linux 5.15.173", "", " * Jammy update: v5.15.173 upstream stable release (LP: #2089541) //", " CVE-2024-41080", " - io_uring: fix possible deadlock in io_register_iowq_max_workers()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Add a tracepoint to show the results of nfs_set_cache_invalid()", " - NFSv3: handle out-of-order write replies.", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - can: c_can: fix {rx,tx}_errors statistics", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - io_uring: rename kiocb_end_write() local helper", " - fs: create kiocb_{start,end}_write() helpers", " - io_uring: use kiocb_{start,end}_write() helpers", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - ALSA: usb-audio: Support jack detection on Dell dock", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ALSA: usb-audio: Add endianness annotations", " - Linux 5.15.172", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-42291", " - ice: Add a per-VF limit on number of FDIR filters", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405)", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - ACPI: PRM: Remove unnecessary blank lines", " - ACPI: PRM: Change handler_addr type to void pointer", " - cgroup: Fix potential overflow issue when checking max_depth", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - mac80211: do drv_reconfig_complete() before restarting all", " - mac80211: Add support to trigger sta disconnect on hardware restart", " - wifi: iwlwifi: mvm: disconnect station vifs if recovery failed", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - gtp: allow -1 to be specified as file description from userspace", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - iio: light: veml6030: fix microlux value calculation", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - mm/page_alloc: call check_new_pages() while zone spinlock is not held", " - mm/page_alloc: fix tracepoint mm_page_alloc_zone_locked()", " - mm/page_alloc: split out buddy removal code from rmqueue into separate", " helper", " - mm/page_alloc: rename ALLOC_HIGH to ALLOC_MIN_RESERVE", " - mm/page_alloc: treat RT tasks similar to __GFP_HIGH", " - mm/page_alloc: explicitly record high-order atomic allocations in", " alloc_flags", " - mm/page_alloc: explicitly define what alloc flags deplete min reserves", " - mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations", " accesses reserves", " - Revert \"drm/mipi-dsi: Set the fwnode for mipi_dsi_device\"", " - vt: prevent kernel-infoleak in con_font_get()", " - mac80211: always have ieee80211_sta_restart()", " - Linux 5.15.171", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2023-52913", " - drm/i915: Fix potential context UAFs", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50141", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272)", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - ipv4: give an IPv4 dev to blackhole_netdev", " - RDMA/bnxt_re: Return more meaningful error", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - net: usb: usbnet: fix race in probe failure", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - macsec: don't increment counters for an unrelated SA", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - genetlink: hold RCU in genlmsg_mcast()", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - arm64:uprobe fix the uprobe SWBP_INSN in big-endian", " - KVM: s390: gaccess: Check if guest address is in memslot", " - usb: gadget: Add function wakeup support", " - XHCI: Separate PORT and CAPs macros into dedicated file", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - platform/x86: dell-wmi: Ignore suspend notifications", " - arm64/uprobes: change the uprobe_opcode_t typedef to fix the sparse warning", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - platform/x86: dell-sysman: add support for alienware products", " - jfs: Fix sanity check in dbMount", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - net: plip: fix break; causing plip to never transmit", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - net: usb: usbnet: fix name regression", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - ALSA: hda/realtek: Update default depop procedure", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - selinux: improve error checking in sel_write_load()", " - net: phy: dp83822: Fix reset pin definitions", " - Linux 5.15.170", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50142", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50103", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50110", " - xfrm: fix one more kernel-infoleak in algo dumping", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50115", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50116", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50117", " - drm/amd: Guard against bad data for ATIF ACPI method", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50205", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50127", " - net: sched: fix use-after-free in taprio_change()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50128", " - net: wwan: fix global oob in wwan_rtnl_policy", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50167", " - be2net: fix potential memory leak in be_xmit()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50168", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50131", " - tracing: Consider the NULL character when validating the event length", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50143", " - udf: fix uninit-value use in udf_get_fileshortad", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50134", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50148", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50150", " - usb: typec: altmode should keep reference to parent", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50151", " - smb: client: fix OOBs when building SMB2_IOCTL request", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50153", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50154", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50171", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50156", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50208", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50160", " - ALSA: hda/cs8409: Fix possible NULL dereference", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50209", " - RDMA/bnxt_re: Add a check for memory allocation", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50162", " - bpf: devmap: provide rxq after redirect", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50163", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", "", " * kernel:nft \"Could not process rule: Device or resource busy\" on unreferenced", " chain (LP: #2089699)", " - SAUCE: netfilter: nf_tables: Fix EBUSY on deleting unreferenced chain", "", " * WARN in trc_wait_for_one_reader about failed IPIs (LP: #2089373)", " - SAUCE: rcu-tasks: fix mismerge in trc_inspect_reader", " - rcu-tasks: Idle tasks on offline CPUs are in quiescent states", "", " * CVE-2024-35887", " - ax25: fix use-after-free bugs caused by ax25_ds_del_timer", "", " * CVE-2024-40965", " - clk: Add a devm variant of clk_rate_exclusive_get()", " - clk: Provide !COMMON_CLK dummy for devm_clk_rate_exclusive_get()", " - i2c: lpi2c: Avoid calling clk_get_rate during transfer", "", " * CVE-2024-40982", " - ssb: Fix potential NULL pointer dereference in ssb_device_uevent()", "", " * CVE-2024-41066", " - ibmvnic: Add tx check to prevent skb leak", "", " * CVE-2024-42252", " - closures: Change BUG_ON() to WARN_ON()", "", " * CVE-2024-53097", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Jammy update: v5.15.169 upstream stable release (LP: #2088231)", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - udf: New directory iteration code", " - udf: Convert udf_expand_dir_adinicb() to new directory iteration", " - udf: Move udf_expand_dir_adinicb() to its callsite", " - udf: Implement searching for directory entry using new iteration code", " - udf: Provide function to mark entry as deleted using new directory iteration", " code", " - udf: Convert udf_rename() to new directory iteration code", " - udf: Convert udf_readdir() to new directory iteration", " - udf: Convert udf_lookup() to use new directory iteration code", " - udf: Convert udf_get_parent() to new directory iteration code", " - udf: Convert empty_dir() to new directory iteration code", " - udf: Convert udf_rmdir() to new directory iteration code", " - udf: Convert udf_unlink() to new directory iteration code", " - udf: Implement adding of dir entries using new iteration code", " - udf: Convert udf_add_nondir() to new directory iteration", " - udf: Convert udf_mkdir() to new directory iteration code", " - udf: Convert udf_link() to new directory iteration code", " - udf: Remove old directory iteration code", " - udf: Handle error when expanding directory", " - udf: Don't return bh from udf_expand_dir_adinicb()", " - udf: Fix bogus checksum computation in udf_rename()", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: add missing static descriptor and inline keyword", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", " - arm64: probes: Remove broken LDR (literal) uprobe support", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1", " - fat: fix uninitialized variable", " - mm/swapfile: skip HugeTLB pages for unuse_vma", " - secretmem: disable memfd_secret() if arch cannot set direct map", " - dm-crypt, dm-verity: disable tasklets", " - KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()", " - drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - io_uring/sqpoll: do not put cpumask on stack", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", " - io_uring/sqpoll: close race on waiting for sqring entries", " - drm/radeon: Fix encoder->possible_clones", " - drm/vmwgfx: Handle surface check failure correctly", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: veml6030: fix IIO device retrieval from embedded device", " - iio: light: opt3001: add missing full-scale range value", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - parport: Proper fix for array out-of-bounds access", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/apic: Always explicitly disarm TSC-deadline timer", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", " - pinctrl: ocelot: fix system hang on level based interrupts", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", " - mptcp: track and update contiguous data status", " - mptcp: handle consistently DSS corruption", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - nilfs2: propagate directory read errors from nilfs_find_entry()", " - powerpc/mm: Always update max/min_low_pfn in mem_topology_setup()", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 5.15.169", "" ], "package": "linux", "version": "5.15.0-132.143", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2093735, 1786013, 2093146, 2089541, 2089541, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089699, 2089373, 2086606, 2087853, 2088231 ], "author": "Stefan Bader ", "date": "Wed, 15 Jan 2025 15:52:39 +0100" } ], "notes": "linux-headers-5.15.0-133-generic version '5.15.0-133.144' (source package linux version '5.15.0-133.144') was added. linux-headers-5.15.0-133-generic version '5.15.0-133.144' has the same source package name, linux, as removed package linux-headers-5.15.0-131. As such we can use the source package version of the removed package, '5.15.0-131.141', 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.15.0-133-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "5.15.0-131.141", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "5.15.0-133.144", "version": "5.15.0-133.144" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.15.0-133.144", "" ], "package": "linux-signed", "version": "5.15.0-133.144", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 19:12:02 +0100" }, { "cves": [], "log": [ "", " * Main version: 5.15.0-132.143", "" ], "package": "linux-signed", "version": "5.15.0-132.143", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Wed, 15 Jan 2025 15:57:35 +0100" }, { "cves": [], "log": [ "", " * Main version: 5.15.0-132.142", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "5.15.0-132.142", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Mon, 13 Jan 2025 04:02:28 +0300" } ], "notes": "linux-image-5.15.0-133-generic version '5.15.0-133.144' (source package linux-signed version '5.15.0-133.144') was added. linux-image-5.15.0-133-generic version '5.15.0-133.144' has the same source package name, linux-signed, as removed package linux-image-5.15.0-131-generic. As such we can use the source package version of the removed package, '5.15.0-131.141', 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.15.0-133-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-131.141", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.15.0-133.144", "version": "5.15.0-133.144" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-41080", "url": "https://ubuntu.com/security/CVE-2024-41080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: fix possible deadlock in io_register_iowq_max_workers() The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee (\"io_uring: drop ctx->uring_lock before acquiring sqd->lock\"), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-42291", "url": "https://ubuntu.com/security/CVE-2024-42291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice.", "cve_priority": "medium", "cve_public_date": "2024-08-17 09:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2023-52913", "url": "https://ubuntu.com/security/CVE-2023-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential context UAFs gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. [tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)", "cve_priority": "medium", "cve_public_date": "2024-08-21 07:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50141", "url": "https://ubuntu.com/security/CVE-2024-50141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50142", "url": "https://ubuntu.com/security/CVE-2024-50142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a (\"xfrm: Validate address prefix lengths in the xfrm selector.\") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50103", "url": "https://ubuntu.com/security/CVE-2024-50103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50110", "url": "https://ubuntu.com/security/CVE-2024-50110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix one more kernel-infoleak in algo dumping During fuzz testing, the following issue was discovered: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Bytes 328-379 of 732 are uninitialized Memory access of size 732 starts at ffff88800e18e000 Data copied to user address 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Fixes copying of xfrm algorithms where some random data of the structure fields can end up in userspace. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space. A similar issue was resolved in the commit 8222d5910dae (\"xfrm: Zero padding when dumping algos and encap\") Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50115", "url": "https://ubuntu.com/security/CVE-2024-50115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50116", "url": "https://ubuntu.com/security/CVE-2024-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50117", "url": "https://ubuntu.com/security/CVE-2024-50117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50205", "url": "https://ubuntu.com/security/CVE-2024-50205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b (\"ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50127", "url": "https://ubuntu.com/security/CVE-2024-50127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50128", "url": "https://ubuntu.com/security/CVE-2024-50128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 (\"net: qualcomm: rmnet: fix global oob in rmnet_policy\"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of `nla_parse_nested_deprecated`, use correct size `IFLA_WWAN_MAX` here to fix this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50167", "url": "https://ubuntu.com/security/CVE-2024-50167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50168", "url": "https://ubuntu.com/security/CVE-2024-50168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50131", "url": "https://ubuntu.com/security/CVE-2024-50131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50143", "url": "https://ubuntu.com/security/CVE-2024-50143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50134", "url": "https://ubuntu.com/security/CVE-2024-50134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a \"memcpy: detected field-spanning write error\" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field \"p->data\" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50148", "url": "https://ubuntu.com/security/CVE-2024-50148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock's resource. To solve above issue just return bnep_sock_init()'s return value in bnep_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50150", "url": "https://ubuntu.com/security/CVE-2024-50150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50151", "url": "https://ubuntu.com/security/CVE-2024-50151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e \"print('a')for 1..1024\") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50153", "url": "https://ubuntu.com/security/CVE-2024-50153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50154", "url": "https://ubuntu.com/security/CVE-2024-50154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). \"\"\" We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. \"\"\" The commit 83fccfc3940c (\"inet: fix potential deadlock in reqsk_queue_unlink()\") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50171", "url": "https://ubuntu.com/security/CVE-2024-50171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50156", "url": "https://ubuntu.com/security/CVE-2024-50156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since \"dump_addr\" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print \"Registers not stored\" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`. Patchwork: https://patchwork.freedesktop.org/patch/619657/", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50208", "url": "https://ubuntu.com/security/CVE-2024-50208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50160", "url": "https://ubuntu.com/security/CVE-2024-50160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50209", "url": "https://ubuntu.com/security/CVE-2024-50209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50162", "url": "https://ubuntu.com/security/CVE-2024-50162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set. This is particularly bad since accessing ingress_ifindex, e.g. SEC(\"xdp\") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC(\"xdp/devmap\") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk(\"ifindex %i\", pkt->ingress_ifindex); return XDP_PASS; } depends on access to rxq, so a NULL pointer gets dereferenced: <1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 574.475188] #PF: supervisor read access in kernel mode <1>[ 574.475194] #PF: error_code(0x0000) - not-present page <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 <4>[ 574.475231] Workqueue: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Call Trace: <4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490 <4>[ 574.475346] ? kmem_cache_free+0x257/0x280 <4>[ 574.475357] ? exc_page_fault+0x67/0x150 <4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30 <4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475386] bq_xmit_all+0x158/0x420 <4>[ 574.475397] __dev_flush+0x30/0x90 <4>[ 574.475407] veth_poll+0x216/0x250 [veth] <4>[ 574.475421] __napi_poll+0x28/0x1c0 <4>[ 574.475430] net_rx_action+0x32d/0x3a0 <4>[ 574.475441] handle_softirqs+0xcb/0x2c0 <4>[ 574.475451] do_softirq+0x40/0x60 <4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70 <4>[ 574.475471] __dev_queue_xmit+0x268/0xe40 <4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420 <4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0 <4>[ 574.475502] ip6_finish_output2+0x2be/0x640 <4>[ 574.475512] ? nf_hook_slow+0x42/0xf0 <4>[ 574.475521] ip6_finish_output+0x194/0x300 <4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 574.475538] mld_sendpack+0x17c/0x240 <4>[ 574.475548] mld_ifc_work+0x192/0x410 <4>[ 574.475557] process_one_work+0x15d/0x380 <4>[ 574.475566] worker_thread+0x29d/0x3a0 <4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? __pfx_kthread+0x10/0x10 <4>[ 574.475606] ret_from_fork+0x31/0x50 <4>[ 574.475615] ? __pfx_kthread+0x10/0x10 <4>[ 574.475623] ret_from_fork_asm+0x1a/0x ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50163", "url": "https://ubuntu.com/security/CVE-2024-50163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-35887", "url": "https://ubuntu.com/security/CVE-2024-35887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.", "cve_priority": "low", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2024-40965", "url": "https://ubuntu.com/security/CVE-2024-40965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: lpi2c: Avoid calling clk_get_rate during transfer Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-40982", "url": "https://ubuntu.com/security/CVE-2024-40982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ssb: Fix potential NULL pointer dereference in ssb_device_uevent() The ssb_device_uevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL. To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-41066", "url": "https://ubuntu.com/security/CVE-2024-41066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] \tconsumer_index^ tx_buff == [skb=null, skb=, skb=, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-42252", "url": "https://ubuntu.com/security/CVE-2024-42252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s", "cve_priority": "medium", "cve_public_date": "2024-08-08 09:15:00 UTC" }, { "cve": "CVE-2024-53097", "url": "https://ubuntu.com/security/CVE-2024-53097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: krealloc: Fix MTE false alarm in __do_krealloc This patch addresses an issue introduced by commit 1a83a716ec233 (\"mm: krealloc: consider spare memory for __GFP_ZERO\") which causes MTE (Memory Tagging Extension) to falsely report a slab-out-of-bounds error. The problem occurs when zeroing out spare memory in __do_krealloc. The original code only considered software-based KASAN and did not account for MTE. It does not reset the KASAN tag before calling memset, leading to a mismatch between the pointer tag and the memory tag, resulting in a false positive. Example of the error: ================================================================== swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188 swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1 swapper/0: Pointer tag: [f4], memory tag: [fe] swapper/0: swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12. swapper/0: Hardware name: MT6991(ENG) (DT) swapper/0: Call trace: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c swapper/0: el1h_64_sync_handler+0x80/0xcc swapper/0: el1h_64_sync+0x68/0x6c swapper/0: __memset+0x84/0x188 swapper/0: btf_populate_kfunc_set+0x280/0x3d8 swapper/0: __register_btf_kfunc_id_set+0x43c/0x468 swapper/0: register_btf_kfunc_id_set+0x48/0x60 swapper/0: register_nf_nat_bpf+0x1c/0x40 swapper/0: nf_nat_init+0xc0/0x128 swapper/0: do_one_initcall+0x184/0x464 swapper/0: do_initcall_level+0xdc/0x1b0 swapper/0: do_initcalls+0x70/0xc0 swapper/0: do_basic_setup+0x1c/0x28 swapper/0: kernel_init_freeable+0x144/0x1b8 swapper/0: kernel_init+0x20/0x1a8 swapper/0: ret_from_fork+0x10/0x20 ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093735, 1786013, 2093146, 2089541, 2089541, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089699, 2089373, 2086606, 2087853, 2088231 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "5.15.0-133.144", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:33 +0100" }, { "cves": [ { "cve": "CVE-2024-41080", "url": "https://ubuntu.com/security/CVE-2024-41080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: fix possible deadlock in io_register_iowq_max_workers() The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee (\"io_uring: drop ctx->uring_lock before acquiring sqd->lock\"), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-42291", "url": "https://ubuntu.com/security/CVE-2024-42291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice.", "cve_priority": "medium", "cve_public_date": "2024-08-17 09:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2023-52913", "url": "https://ubuntu.com/security/CVE-2023-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential context UAFs gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. [tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)", "cve_priority": "medium", "cve_public_date": "2024-08-21 07:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50141", "url": "https://ubuntu.com/security/CVE-2024-50141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50142", "url": "https://ubuntu.com/security/CVE-2024-50142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a (\"xfrm: Validate address prefix lengths in the xfrm selector.\") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50103", "url": "https://ubuntu.com/security/CVE-2024-50103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50110", "url": "https://ubuntu.com/security/CVE-2024-50110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix one more kernel-infoleak in algo dumping During fuzz testing, the following issue was discovered: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Bytes 328-379 of 732 are uninitialized Memory access of size 732 starts at ffff88800e18e000 Data copied to user address 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Fixes copying of xfrm algorithms where some random data of the structure fields can end up in userspace. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space. A similar issue was resolved in the commit 8222d5910dae (\"xfrm: Zero padding when dumping algos and encap\") Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50115", "url": "https://ubuntu.com/security/CVE-2024-50115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50116", "url": "https://ubuntu.com/security/CVE-2024-50116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50117", "url": "https://ubuntu.com/security/CVE-2024-50117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50205", "url": "https://ubuntu.com/security/CVE-2024-50205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b (\"ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50127", "url": "https://ubuntu.com/security/CVE-2024-50127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50128", "url": "https://ubuntu.com/security/CVE-2024-50128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 (\"net: qualcomm: rmnet: fix global oob in rmnet_policy\"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of `nla_parse_nested_deprecated`, use correct size `IFLA_WWAN_MAX` here to fix this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50167", "url": "https://ubuntu.com/security/CVE-2024-50167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50168", "url": "https://ubuntu.com/security/CVE-2024-50168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50131", "url": "https://ubuntu.com/security/CVE-2024-50131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50143", "url": "https://ubuntu.com/security/CVE-2024-50143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50134", "url": "https://ubuntu.com/security/CVE-2024-50134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a \"memcpy: detected field-spanning write error\" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field \"p->data\" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50148", "url": "https://ubuntu.com/security/CVE-2024-50148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock's resource. To solve above issue just return bnep_sock_init()'s return value in bnep_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50150", "url": "https://ubuntu.com/security/CVE-2024-50150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50151", "url": "https://ubuntu.com/security/CVE-2024-50151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e \"print('a')for 1..1024\") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50153", "url": "https://ubuntu.com/security/CVE-2024-50153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device().", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50154", "url": "https://ubuntu.com/security/CVE-2024-50154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). \"\"\" We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. \"\"\" The commit 83fccfc3940c (\"inet: fix potential deadlock in reqsk_queue_unlink()\") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50171", "url": "https://ubuntu.com/security/CVE-2024-50171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50156", "url": "https://ubuntu.com/security/CVE-2024-50156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since \"dump_addr\" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print \"Registers not stored\" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`. Patchwork: https://patchwork.freedesktop.org/patch/619657/", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50208", "url": "https://ubuntu.com/security/CVE-2024-50208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50160", "url": "https://ubuntu.com/security/CVE-2024-50160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50209", "url": "https://ubuntu.com/security/CVE-2024-50209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50162", "url": "https://ubuntu.com/security/CVE-2024-50162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set. This is particularly bad since accessing ingress_ifindex, e.g. SEC(\"xdp\") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC(\"xdp/devmap\") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk(\"ifindex %i\", pkt->ingress_ifindex); return XDP_PASS; } depends on access to rxq, so a NULL pointer gets dereferenced: <1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 574.475188] #PF: supervisor read access in kernel mode <1>[ 574.475194] #PF: error_code(0x0000) - not-present page <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 <4>[ 574.475231] Workqueue: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Call Trace: <4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490 <4>[ 574.475346] ? kmem_cache_free+0x257/0x280 <4>[ 574.475357] ? exc_page_fault+0x67/0x150 <4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30 <4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475386] bq_xmit_all+0x158/0x420 <4>[ 574.475397] __dev_flush+0x30/0x90 <4>[ 574.475407] veth_poll+0x216/0x250 [veth] <4>[ 574.475421] __napi_poll+0x28/0x1c0 <4>[ 574.475430] net_rx_action+0x32d/0x3a0 <4>[ 574.475441] handle_softirqs+0xcb/0x2c0 <4>[ 574.475451] do_softirq+0x40/0x60 <4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70 <4>[ 574.475471] __dev_queue_xmit+0x268/0xe40 <4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420 <4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0 <4>[ 574.475502] ip6_finish_output2+0x2be/0x640 <4>[ 574.475512] ? nf_hook_slow+0x42/0xf0 <4>[ 574.475521] ip6_finish_output+0x194/0x300 <4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 574.475538] mld_sendpack+0x17c/0x240 <4>[ 574.475548] mld_ifc_work+0x192/0x410 <4>[ 574.475557] process_one_work+0x15d/0x380 <4>[ 574.475566] worker_thread+0x29d/0x3a0 <4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? __pfx_kthread+0x10/0x10 <4>[ 574.475606] ret_from_fork+0x31/0x50 <4>[ 574.475615] ? __pfx_kthread+0x10/0x10 <4>[ 574.475623] ret_from_fork_asm+0x1a/0x ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-50163", "url": "https://ubuntu.com/security/CVE-2024-50163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake.", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2024-35887", "url": "https://ubuntu.com/security/CVE-2024-35887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.", "cve_priority": "low", "cve_public_date": "2024-05-19 09:15:00 UTC" }, { "cve": "CVE-2024-40965", "url": "https://ubuntu.com/security/CVE-2024-40965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: lpi2c: Avoid calling clk_get_rate during transfer Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-40982", "url": "https://ubuntu.com/security/CVE-2024-40982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ssb: Fix potential NULL pointer dereference in ssb_device_uevent() The ssb_device_uevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL. To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-07-12 13:15:00 UTC" }, { "cve": "CVE-2024-41066", "url": "https://ubuntu.com/security/CVE-2024-41066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] \tconsumer_index^ tx_buff == [skb=null, skb=, skb=, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.", "cve_priority": "medium", "cve_public_date": "2024-07-29 15:15:00 UTC" }, { "cve": "CVE-2024-42252", "url": "https://ubuntu.com/security/CVE-2024-42252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s", "cve_priority": "medium", "cve_public_date": "2024-08-08 09:15:00 UTC" }, { "cve": "CVE-2024-53097", "url": "https://ubuntu.com/security/CVE-2024-53097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: krealloc: Fix MTE false alarm in __do_krealloc This patch addresses an issue introduced by commit 1a83a716ec233 (\"mm: krealloc: consider spare memory for __GFP_ZERO\") which causes MTE (Memory Tagging Extension) to falsely report a slab-out-of-bounds error. The problem occurs when zeroing out spare memory in __do_krealloc. The original code only considered software-based KASAN and did not account for MTE. It does not reset the KASAN tag before calling memset, leading to a mismatch between the pointer tag and the memory tag, resulting in a false positive. Example of the error: ================================================================== swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188 swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1 swapper/0: Pointer tag: [f4], memory tag: [fe] swapper/0: swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12. swapper/0: Hardware name: MT6991(ENG) (DT) swapper/0: Call trace: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c swapper/0: el1h_64_sync_handler+0x80/0xcc swapper/0: el1h_64_sync+0x68/0x6c swapper/0: __memset+0x84/0x188 swapper/0: btf_populate_kfunc_set+0x280/0x3d8 swapper/0: __register_btf_kfunc_id_set+0x43c/0x468 swapper/0: register_btf_kfunc_id_set+0x48/0x60 swapper/0: register_nf_nat_bpf+0x1c/0x40 swapper/0: nf_nat_init+0xc0/0x128 swapper/0: do_one_initcall+0x184/0x464 swapper/0: do_initcall_level+0xdc/0x1b0 swapper/0: do_initcalls+0x70/0xc0 swapper/0: do_basic_setup+0x1c/0x28 swapper/0: kernel_init_freeable+0x144/0x1b8 swapper/0: kernel_init+0x20/0x1a8 swapper/0: ret_from_fork+0x10/0x20 ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" } ], "log": [ "", " * jammy/linux: 5.15.0-132.143 -proposed tracker (LP: #2093735)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - kvm: x86: Fix xstate_required_size() to follow XSTATE alignment rule", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * Jammy update: v5.15.173 upstream stable release (LP: #2089541)", " - 9p: Avoid creating multiple slab caches with the same name", " - irqchip/ocelot: Fix trigger register address", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: marvell/cesa - Disable hash algorithms", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - powerpc/powernv: Free name on error in opal_event_init()", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - md/raid10: improve code of mrdev in raid10_sync_request", " - mm/memory: add non-anonymous page check in the copy_present_page()", " - udf: Allocate name buffer in directory iterator on heap", " - udf: Avoid directory type conversion failure due to ENOMEM", " - 9p: fix slab cache name creation for real", " - Linux 5.15.173", "", " * Jammy update: v5.15.173 upstream stable release (LP: #2089541) //", " CVE-2024-41080", " - io_uring: fix possible deadlock in io_register_iowq_max_workers()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Add a tracepoint to show the results of nfs_set_cache_invalid()", " - NFSv3: handle out-of-order write replies.", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - can: c_can: fix {rx,tx}_errors statistics", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - io_uring: rename kiocb_end_write() local helper", " - fs: create kiocb_{start,end}_write() helpers", " - io_uring: use kiocb_{start,end}_write() helpers", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - ALSA: usb-audio: Support jack detection on Dell dock", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ALSA: usb-audio: Add endianness annotations", " - Linux 5.15.172", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-42291", " - ice: Add a per-VF limit on number of FDIR filters", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Jammy update: v5.15.172 upstream stable release (LP: #2089533) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405)", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - ACPI: PRM: Remove unnecessary blank lines", " - ACPI: PRM: Change handler_addr type to void pointer", " - cgroup: Fix potential overflow issue when checking max_depth", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - mac80211: do drv_reconfig_complete() before restarting all", " - mac80211: Add support to trigger sta disconnect on hardware restart", " - wifi: iwlwifi: mvm: disconnect station vifs if recovery failed", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - gtp: allow -1 to be specified as file description from userspace", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - iio: light: veml6030: fix microlux value calculation", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - mm/page_alloc: call check_new_pages() while zone spinlock is not held", " - mm/page_alloc: fix tracepoint mm_page_alloc_zone_locked()", " - mm/page_alloc: split out buddy removal code from rmqueue into separate", " helper", " - mm/page_alloc: rename ALLOC_HIGH to ALLOC_MIN_RESERVE", " - mm/page_alloc: treat RT tasks similar to __GFP_HIGH", " - mm/page_alloc: explicitly record high-order atomic allocations in", " alloc_flags", " - mm/page_alloc: explicitly define what alloc flags deplete min reserves", " - mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations", " accesses reserves", " - Revert \"drm/mipi-dsi: Set the fwnode for mipi_dsi_device\"", " - vt: prevent kernel-infoleak in con_font_get()", " - mac80211: always have ieee80211_sta_restart()", " - Linux 5.15.171", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2023-52913", " - drm/i915: Fix potential context UAFs", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50141", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", "", " * Jammy update: v5.15.171 upstream stable release (LP: #2089405) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272)", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - ipv4: give an IPv4 dev to blackhole_netdev", " - RDMA/bnxt_re: Return more meaningful error", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - net: usb: usbnet: fix race in probe failure", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - macsec: don't increment counters for an unrelated SA", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - genetlink: hold RCU in genlmsg_mcast()", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - arm64:uprobe fix the uprobe SWBP_INSN in big-endian", " - KVM: s390: gaccess: Check if guest address is in memslot", " - usb: gadget: Add function wakeup support", " - XHCI: Separate PORT and CAPs macros into dedicated file", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - platform/x86: dell-wmi: Ignore suspend notifications", " - arm64/uprobes: change the uprobe_opcode_t typedef to fix the sparse warning", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - platform/x86: dell-sysman: add support for alienware products", " - jfs: Fix sanity check in dbMount", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - net: plip: fix break; causing plip to never transmit", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - net: usb: usbnet: fix name regression", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - ALSA: hda/realtek: Update default depop procedure", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - selinux: improve error checking in sel_write_load()", " - net: phy: dp83822: Fix reset pin definitions", " - Linux 5.15.170", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50142", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50103", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50110", " - xfrm: fix one more kernel-infoleak in algo dumping", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50115", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50116", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50117", " - drm/amd: Guard against bad data for ATIF ACPI method", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50205", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50127", " - net: sched: fix use-after-free in taprio_change()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50128", " - net: wwan: fix global oob in wwan_rtnl_policy", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50167", " - be2net: fix potential memory leak in be_xmit()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50168", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50131", " - tracing: Consider the NULL character when validating the event length", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50143", " - udf: fix uninit-value use in udf_get_fileshortad", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50134", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50148", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50150", " - usb: typec: altmode should keep reference to parent", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50151", " - smb: client: fix OOBs when building SMB2_IOCTL request", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50153", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50154", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50171", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50156", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50208", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50160", " - ALSA: hda/cs8409: Fix possible NULL dereference", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50209", " - RDMA/bnxt_re: Add a check for memory allocation", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50162", " - bpf: devmap: provide rxq after redirect", "", " * Jammy update: v5.15.170 upstream stable release (LP: #2089272) //", " CVE-2024-50163", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", "", " * kernel:nft \"Could not process rule: Device or resource busy\" on unreferenced", " chain (LP: #2089699)", " - SAUCE: netfilter: nf_tables: Fix EBUSY on deleting unreferenced chain", "", " * WARN in trc_wait_for_one_reader about failed IPIs (LP: #2089373)", " - SAUCE: rcu-tasks: fix mismerge in trc_inspect_reader", " - rcu-tasks: Idle tasks on offline CPUs are in quiescent states", "", " * CVE-2024-35887", " - ax25: fix use-after-free bugs caused by ax25_ds_del_timer", "", " * CVE-2024-40965", " - clk: Add a devm variant of clk_rate_exclusive_get()", " - clk: Provide !COMMON_CLK dummy for devm_clk_rate_exclusive_get()", " - i2c: lpi2c: Avoid calling clk_get_rate during transfer", "", " * CVE-2024-40982", " - ssb: Fix potential NULL pointer dereference in ssb_device_uevent()", "", " * CVE-2024-41066", " - ibmvnic: Add tx check to prevent skb leak", "", " * CVE-2024-42252", " - closures: Change BUG_ON() to WARN_ON()", "", " * CVE-2024-53097", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Jammy update: v5.15.169 upstream stable release (LP: #2088231)", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - udf: New directory iteration code", " - udf: Convert udf_expand_dir_adinicb() to new directory iteration", " - udf: Move udf_expand_dir_adinicb() to its callsite", " - udf: Implement searching for directory entry using new iteration code", " - udf: Provide function to mark entry as deleted using new directory iteration", " code", " - udf: Convert udf_rename() to new directory iteration code", " - udf: Convert udf_readdir() to new directory iteration", " - udf: Convert udf_lookup() to use new directory iteration code", " - udf: Convert udf_get_parent() to new directory iteration code", " - udf: Convert empty_dir() to new directory iteration code", " - udf: Convert udf_rmdir() to new directory iteration code", " - udf: Convert udf_unlink() to new directory iteration code", " - udf: Implement adding of dir entries using new iteration code", " - udf: Convert udf_add_nondir() to new directory iteration", " - udf: Convert udf_mkdir() to new directory iteration code", " - udf: Convert udf_link() to new directory iteration code", " - udf: Remove old directory iteration code", " - udf: Handle error when expanding directory", " - udf: Don't return bh from udf_expand_dir_adinicb()", " - udf: Fix bogus checksum computation in udf_rename()", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: add missing static descriptor and inline keyword", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", " - arm64: probes: Remove broken LDR (literal) uprobe support", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1", " - fat: fix uninitialized variable", " - mm/swapfile: skip HugeTLB pages for unuse_vma", " - secretmem: disable memfd_secret() if arch cannot set direct map", " - dm-crypt, dm-verity: disable tasklets", " - KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()", " - drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - io_uring/sqpoll: do not put cpumask on stack", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", " - io_uring/sqpoll: close race on waiting for sqring entries", " - drm/radeon: Fix encoder->possible_clones", " - drm/vmwgfx: Handle surface check failure correctly", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: veml6030: fix IIO device retrieval from embedded device", " - iio: light: opt3001: add missing full-scale range value", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - parport: Proper fix for array out-of-bounds access", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/apic: Always explicitly disarm TSC-deadline timer", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", " - pinctrl: ocelot: fix system hang on level based interrupts", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", " - mptcp: track and update contiguous data status", " - mptcp: handle consistently DSS corruption", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - nilfs2: propagate directory read errors from nilfs_find_entry()", " - powerpc/mm: Always update max/min_low_pfn in mem_topology_setup()", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 5.15.169", "" ], "package": "linux", "version": "5.15.0-132.143", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2093735, 1786013, 2093146, 2089541, 2089541, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089533, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089405, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089272, 2089699, 2089373, 2086606, 2087853, 2088231 ], "author": "Stefan Bader ", "date": "Wed, 15 Jan 2025 15:52:39 +0100" } ], "notes": "linux-modules-5.15.0-133-generic version '5.15.0-133.144' (source package linux version '5.15.0-133.144') was added. linux-modules-5.15.0-133-generic version '5.15.0-133.144' has the same source package name, linux, as removed package linux-headers-5.15.0-131. As such we can use the source package version of the removed package, '5.15.0-131.141', 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.15.0-131", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-131.141", "version": "5.15.0-131.141" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-headers-5.15.0-131-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-131.141", "version": "5.15.0-131.141" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-image-5.15.0-131-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "5.15.0-131.141", "version": "5.15.0-131.141" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-modules-5.15.0-131-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-131.141", "version": "5.15.0-131.141" }, "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 22.04 jammy image from release image serial 20250219 to 20250220", "from_series": "jammy", "to_series": "jammy", "from_serial": "20250219", "to_serial": "20250220", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }