CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43480 – ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition
https://notcve.org/view.php?id=CVE-2026-43480
13 May 2026 — In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition The acp3x_5682_init() function did not check the return value of clk_get(), which could lead to dereferencing error pointers in rt5682_clk_enable(). Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding proper IS_ERR() checks for both clock acquisitions. • https://git.kernel.org/stable/c/6b8e4e7db3cd236a2cbb720360fb135087a2ac1d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2026-43479 – net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect
https://notcve.org/view.php?id=CVE-2026-43479
13 May 2026 — In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect Remove redundant netif_napi_del() call from disconnect path. A WARN may be triggered in __netif_napi_del_locked() during USB device disconnect: WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350 This happens because netif_napi_del() is called in the disconnect path while NAPI is still enabled. However, it is not necessary to call netif_napi_... • https://git.kernel.org/stable/c/e110bc82589752909e283ba5cbc160e0ab56c085 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2026-43477 – drm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTL
https://notcve.org/view.php?id=CVE-2026-43477
13 May 2026 — In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTL Apparently ICL may hang with an MCE if we write TRANS_VRR_VMAX/FLIPLINE before enabling TRANS_DDI_FUNC_CTL. Personally I was only able to reproduce a hang (on an Dell XPS 7390 2-in-1) with an external display connected via a dock using a dodgy type-C cable that made the link training fail. After the failed link training the machine would hang. TGL seemed immune to the pro... • https://git.kernel.org/stable/c/dda7dcd9da73c5327aef42b89f0519bb51e84217 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2026-43476 – iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas()
https://notcve.org/view.php?id=CVE-2026-43476
13 May 2026 — In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas() sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) instead of the intended __be32 element size (4 bytes). Use sizeof(*meas) to correctly match the buffer element type. • https://git.kernel.org/stable/c/8f3f130852785dac0759843835ca97c3bacc2b10 •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2026-43500 – rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present
https://notcve.org/view.php?id=CVE-2026-43500
11 May 2026 — In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained s... • https://git.kernel.org/stable/c/d0d5c0cd1e711c98703f3544c1e6fc1372898de5 • CWE-787: Out-of-bounds Write •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43475 – scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT
https://notcve.org/view.php?id=CVE-2026-43475
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT This resolves the follow splat and lock-up when running with PREEMPT_RT enabled on Hyper-V: [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry i... • https://git.kernel.org/stable/c/d86adf482b843b3a58a9ec3b7c1ccdbf7c705db1 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2026-43474 – fs: init flags_valid before calling vfs_fileattr_get
https://notcve.org/view.php?id=CVE-2026-43474
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: fs: init flags_valid before calling vfs_fileattr_get syzbot reported a uninit-value bug in [1]. Similar to the "*get" context where the kernel's internal file_kattr structure is initialized before calling vfs_fileattr_get(), we should use the same mechanism when using fa. [1] BUG: KMSAN: uninit-value in fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517 fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517 vfs_fileattr_get fs/file_attr.c:94 [i... • https://git.kernel.org/stable/c/be7efb2d20d67f334a7de2aef77ae6c69367e646 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2026-43473 – scsi: mpi3mr: Add NULL checks when resetting request and reply queues
https://notcve.org/view.php?id=CVE-2026-43473
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Add NULL checks when resetting request and reply queues The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash. Add NULL pointer checks for reply and request queues befo... • https://git.kernel.org/stable/c/fe6db615156573d3f6a37564b8a590cb03bbaf25 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43472 – unshare: fix unshare_fs() handling
https://notcve.org/view.php?id=CVE-2026-43472
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: unshare: fix unshare_fs() handling There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness] > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness... • https://git.kernel.org/stable/c/741a295130606143edbf9fc740f633dbc1e6225f •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2026-43471 – scsi: ufs: core: Fix possible NULL pointer dereference in ufshcd_add_command_trace()
https://notcve.org/view.php?id=CVE-2026-43471
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix possible NULL pointer dereference in ufshcd_add_command_trace() The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL pointer dereference when accessing hwq->id. This can happen if ufshcd_mcq_req_to_hwq() returns NULL. This patch adds a NULL check for hwq before accessing its id field to prevent a kernel crash. Kernel log excerpt: [