Page 40 of 12836 results (0.006 seconds)

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

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: rpmsg: core: fix race in driver_override_show() and use core helper The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string... • https://git.kernel.org/stable/c/39e47767ec9b22f844c2a07c9d329256960d4021 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band() Simplify the code by using device managed memory allocations. This also fixes a memory leak in rtw_register_hw(). The supported bands were not freed in the error path. Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*"). • https://git.kernel.org/stable/c/e3037485c68ec1a299ff41160d8fedbd4abc29b9 • CWE-401: Missing Release of Memory after Effective Lifetime •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: most: core: fix resource leak in most_register_interface error paths The function most_register_interface() did not correctly release resources if it failed early (before registering the device). In these cases, it returned an error code immediately, leaking the memory allocated for the interface. Fix this by initializing the device early via device_initialize() and calling put_device() on all error paths. The most_register_interface() is e... • https://git.kernel.org/stable/c/723de0f9171eeb49a3ae98cae82ebbbb992b3a7c • CWE-401: Missing Release of Memory after Effective Lifetime •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: hfsplus: ensure sb->s_fs_info is always cleaned up When hfsplus was converted to the new mount api a bug was introduced by changing the allocation pattern of sb->s_fs_info. If setup_bdev_super() fails after a new superblock has been allocated by sget_fc(), but before hfsplus_fill_super() takes ownership of the filesystem-specific s_fs_info data it was leaked. Fix this by freeing sb->s_fs_info in hfsplus_kill_super(). • https://git.kernel.org/stable/c/432f7c78cb000a3151fa0d39585b000312f50d7e •

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

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix double free related to rereg_user_mr If IB_MR_REREG_TRANS is set during rereg_user_mr, the umem will be released and a new one will be allocated in irdma_rereg_mr_trans. If any step of irdma_rereg_mr_trans fails after the new umem is allocated, it releases the umem, but does not set iwmr->region to NULL. The problem is that this failure is propagated to the user, who will then call ibv_dereg_mr (as they should). Then, the de... • https://git.kernel.org/stable/c/715fdb3b30541cc8180b7cdc6aa9f8c307afdf25 • CWE-415: Double Free •

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

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: annotate data-races around hdev->req_status __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND; However, several other functions read or write hdev->req_status without holding any lock: - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) - hci_cmd_sync_complete() reads/writes from HCI event completion - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/wr... • https://git.kernel.org/stable/c/f80c5dad7b6467b884c445ffea45985793b4b2d0 •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix zero size inode with non-zero size after log replay When logging that an inode exists, as part of logging a new name or logging new dir entries for a directory, we always set the generation of the logged inode item to 0. This is to signal during log replay (in overwrite_item()), that we should not set the i_size since we only logged that an inode exists, so the i_size of the inode in the subvolume tree must be preserved (as when ... • https://git.kernel.org/stable/c/12fcfd22fe5bf4fe74710232098bc101af497995 •

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

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb. • https://git.kernel.org/stable/c/bc074524e123ded281cde25ebc5661910f9679e3 •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy... • https://git.kernel.org/stable/c/c1d10adb4a521de5760112853f42aaeefcec96eb • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0

06 May 2026 — In the Linux kernel, the following vulnerability has been resolved: srcu: Use irq_work to start GP in tiny SRCU Tiny SRCU's srcu_gp_start_if_needed() directly calls schedule_work(), which acquires the workqueue pool->lock. This causes a lockdep splat when call_srcu() is called with a scheduler lock held, due to: call_srcu() [holding pi_lock] srcu_gp_start_if_needed() schedule_work() -> pool->lock workqueue_init() / create_worker() [holding pool->lock] wake_up_process() -> try_to_wake_up() -> pi_lock Also ad... • https://git.kernel.org/stable/c/d8be81735aa89413b333de488251f0e64e2be591 •