CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48877 – f2fs: let's avoid panic if extent_tree is not created
https://notcve.org/view.php?id=CVE-2022-48877
In the Linux kernel, the following vulnerability has been resolved: f2fs: let's avoid panic if extent_tree is not created This patch avoids the below panic. pc : __lookup_extent_tree+0xd8/0x760 lr : f2fs_do_write_data_page+0x104/0x87c sp : ffffffc010cbb3c0 x29: ffffffc010cbb3e0 x28: 0000000000000000 x27: ffffff8803e7f020 x26: ffffff8803e7ed40 x25: ffffff8803e7f020 x24: ffffffc010cbb460 x23: ffffffc010cbb480 x22: 0000000000000000 x21: 0000000000000000 x20: ffffffff22e90900 x19: 0000000000000000 x18: ffffffc010c5d080 x17: 0000000000000000 x16: 0000000000000020 x15: ffffffdb1acdbb88 x14: ffffff888759e2b0 x13: 0000000000000000 x12: ffffff802da49000 x11: 000000000a001200 x10: ffffff8803e7ed40 x9 : ffffff8023195800 x8 : ffffff802da49078 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0000000000000006 x4 : ffffffc010cbba28 x3 : 0000000000000000 x2 : ffffffc010cbb480 x1 : 0000000000000000 x0 : ffffff8803e7ed40 Call trace: __lookup_extent_tree+0xd8/0x760 f2fs_do_write_data_page+0x104/0x87c f2fs_write_single_data_page+0x420/0xb60 f2fs_write_cache_pages+0x418/0xb1c __f2fs_write_data_pages+0x428/0x58c f2fs_write_data_pages+0x30/0x40 do_writepages+0x88/0x190 __writeback_single_inode+0x48/0x448 writeback_sb_inodes+0x468/0x9e8 __writeback_inodes_wb+0xb8/0x2a4 wb_writeback+0x33c/0x740 wb_do_writeback+0x2b4/0x400 wb_workfn+0xe4/0x34c process_one_work+0x24c/0x5bc worker_thread+0x3e8/0xa50 kthread+0x150/0x1b4 • https://git.kernel.org/stable/c/dd83a9763e29ed7a21c8a43f7a62cd0a6bf74692 https://git.kernel.org/stable/c/ff85a1dbd90d29f73033177ff8d8de4a27d9721c https://git.kernel.org/stable/c/557e85ff9afef6d45020b6f09357111d38033c31 https://git.kernel.org/stable/c/72009139a661ade5cb1da4239734ed02fa1cfff0 https://git.kernel.org/stable/c/2c129e868992621a739bdd57a5bffa3985ef1b91 https://git.kernel.org/stable/c/1c38cdc747f00daf7394535eae5afc4c503c59bb https://git.kernel.org/stable/c/df9d44b645b83fffccfb4e28c1f93376585fdec8 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48875 – wifi: mac80211: sdata can be NULL during AMPDU start
https://notcve.org/view.php?id=CVE-2022-48875
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: sdata can be NULL during AMPDU start ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a deauthentication is ongoing. Here a trace triggering the race with the hostapd test multi_ap_fronthaul_on_ap: (gdb) list *drv_ampdu_action+0x46 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396). 391 int ret = -EOPNOTSUPP; 392 393 might_sleep(); 394 395 sdata = get_bss_sdata(sdata); 396 if (!check_sdata_in_driver(sdata)) 397 return -EIO; 398 399 trace_drv_ampdu_action(local, sdata, params); 400 wlan0: moving STA 02:00:00:00:03:00 to state 3 wlan0: associated wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING) wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0 wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port) wlan0: moving STA 02:00:00:00:03:00 to state 2 wlan0: moving STA 02:00:00:00:03:00 to state 1 wlan0: Removed STA 02:00:00:00:03:00 wlan0: Destroyed STA 02:00:00:00:03:00 BUG: unable to handle page fault for address: fffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Workqueue: phy3 ieee80211_ba_session_work [mac80211] RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211] Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Call Trace: <TASK> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> • https://git.kernel.org/stable/c/187523fa7c2d4c780f775cb869216865c4a909ef https://git.kernel.org/stable/c/a12fd43bd175fa52c82f9740179d38c34ca1b62e https://git.kernel.org/stable/c/c838df8461a601b20dc1b9fb1834d2aad8e2f949 https://git.kernel.org/stable/c/69403bad97aa0162e3d7911b27e25abe774093df •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43882 – exec: Fix ToCToU between perm check and set-uid/gid usage
https://notcve.org/view.php?id=CVE-2024-43882
In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. • https://git.kernel.org/stable/c/d5c3c7e26275a2d83b894d30f7582a42853a958f https://git.kernel.org/stable/c/368f6985d46657b8b466a421dddcacd4051f7ada https://git.kernel.org/stable/c/15469d46ba34559bfe7e3de6659115778c624759 https://git.kernel.org/stable/c/9b424c5d4130d56312e2a3be17efb0928fec4d64 https://git.kernel.org/stable/c/f6cfc6bcfd5e1cf76115b6450516ea4c99897ae1 https://git.kernel.org/stable/c/d2a2a4714d80d09b0f8eb6438ab4224690b7121e https://git.kernel.org/stable/c/90dfbba89ad4f0d9c9744ecbb1adac4aa2ff4f3e https://git.kernel.org/stable/c/f50733b45d865f91db90919f8311e2127 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43867 – drm/nouveau: prime: fix refcount underflow
https://notcve.org/view.php?id=CVE-2024-43867
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix refcount underflow Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow. Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually. (cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5) • https://git.kernel.org/stable/c/ab9ccb96a6e6f95bcde6b8b2a524370efdbfdcd6 https://git.kernel.org/stable/c/3bcb8bba72ce89667fa863054956267c450c47ef https://git.kernel.org/stable/c/906372e753c5027a1dc88743843b6aa2ad1aaecf https://git.kernel.org/stable/c/16998763c62bb465ebc409d0373b9cdcef1a61a6 https://git.kernel.org/stable/c/ebebba4d357b6c67f96776a48ddbaf0060fa4c10 https://git.kernel.org/stable/c/f23cd66933fe76b84d8e282e5606b4d99068c320 https://git.kernel.org/stable/c/2a1b327d57a8ac080977633a18999f032d7e9e3f https://git.kernel.org/stable/c/a9bf3efc33f1fbf88787a277f73494592 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43863 – drm/vmwgfx: Fix a deadlock in dma buf fence polling
https://notcve.org/view.php?id=CVE-2024-43863
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock. • https://git.kernel.org/stable/c/2298e804e96eb3635c39519c8287befd92460303 https://git.kernel.org/stable/c/9e20d028d8d1deb1e7fed18f22ffc01669cf3237 https://git.kernel.org/stable/c/3b933b16c996af8adb6bc1b5748a63dfb41a82bc https://git.kernel.org/stable/c/a8943969f9ead2fd3044fc826140a21622ef830e https://git.kernel.org/stable/c/c98ab18b9f315ff977c2c65d7c71298ef98be8e3 https://git.kernel.org/stable/c/e58337100721f3cc0c7424a18730e4f39844934f •