Page 111 of 3419 results (0.009 seconds)

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: efi: fix NULL-deref in init error path In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated. Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer. • https://git.kernel.org/stable/c/2ff3c97b47521d6700cc6485c7935908dcd2c27c https://git.kernel.org/stable/c/5167f194da6947e19a3e970485ee3ccb44f7958d https://git.kernel.org/stable/c/98086df8b70c06234a8f4290c46064e44dafa0ed https://git.kernel.org/stable/c/f591a42b8f9a9d20e01d0462f4f55d2176ac52ec https://git.kernel.org/stable/c/e6584124b9823151ef586d10dedf565ade50cea6 https://git.kernel.org/stable/c/585a0b2b3ae7903c6abee3087d09c69e955a7794 https://git.kernel.org/stable/c/5fcf75a8a4c3e7ee9122d143684083c9faf20452 https://git.kernel.org/stable/c/4ca71bc0e1995d15486cd7b60845602a2 •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

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: 0

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: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Don't remove map on creater_process and device_release Do not remove the map from the list on error path in fastrpc_init_create_process, instead call fastrpc_map_put, to avoid use-after-free. Do not remove it on fastrpc_device_release either, call fastrpc_map_put instead. The fastrpc_free_map is the only proper place to remove the map. This is called only after the reference count is 0. • https://git.kernel.org/stable/c/b49f6d83e290f17e20f4e5cf31288d3bb4955ea6 https://git.kernel.org/stable/c/aaf5aa44934ad069cac805923c49f6968b9a0d49 https://git.kernel.org/stable/c/4b5c44e924a571d0ad07054de549624fbc04e4d7 https://git.kernel.org/stable/c/193cd853145b63e670bd73740250983af1475330 https://git.kernel.org/stable/c/1b7b7bb400dd13dcb03fc6e591bb7ca4664bbec8 https://git.kernel.org/stable/c/35ddd482345c43d9eec1f3406c0f20a95ed4054b https://git.kernel.org/stable/c/5bb96c8f9268e2fdb0e5321cbc358ee5941efc15 •

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free race condition for maps It is possible that in between calling fastrpc_map_get() until map->fl->lock is taken in fastrpc_free_map(), another thread can call fastrpc_map_lookup() and get a reference to a map that is about to be deleted. Rewrite fastrpc_map_get() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted. Fixes this warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate ... Call trace: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_syscall • https://git.kernel.org/stable/c/c68cfb718c8f97b7f7a50ed66be5feb42d0c8988 https://git.kernel.org/stable/c/556dfdb226ce1e5231d8836159b23f8bb0395bf4 https://git.kernel.org/stable/c/b171d0d2cf1b8387c72c8d325c5d5746fa271e39 https://git.kernel.org/stable/c/61a0890cb95afec5c8a2f4a879de2b6220984ef1 https://git.kernel.org/stable/c/079c78c68714f7d8d58e66c477b0243b31806907 https://git.kernel.org/stable/c/96b328d119eca7563c1edcc4e1039a62e6370ecb •