CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2025-22033 – arm64: Don't call NULL in do_compat_alignment_fixup()
https://notcve.org/view.php?id=CVE-2025-22033
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: arm64: Don't call NULL in do_compat_alignment_fixup() do_alignment_t32_to_handler() only fixes up alignment faults for specific instructions; it returns NULL otherwise (e.g. LDREX). When that's the case, signal to the caller that it needs to proceed with the regular alignment fault handling (i.e. SIGBUS). Without this patch, the kernel panics: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort inf... • https://git.kernel.org/stable/c/3fc24ef32d3b9368f4c103dcd21d6a3f959b4870 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-22029 – exec: fix the racy usage of fs_struct->in_exec
https://notcve.org/view.php?id=CVE-2025-22029
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: exec: fix the racy usage of fs_struct->in_exec check_unsafe_exec() sets fs->in_exec under cred_guard_mutex, then execve() paths clear fs->in_exec lockless. This is fine if exec succeeds, but if it fails we have the following race: T1 sets fs->in_exec = 1, fails, drops cred_guard_mutex T2 sets fs->in_exec = 1 T1 clears fs->in_exec T2 continues with fs->in_exec == 0 Change fs/exec.c to clear fs->in_exec with cred_guard_mutex held. In the Linu... • https://git.kernel.org/stable/c/753a620a7f8e134b444f89fe90873234e894e21a •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2025-22028 – media: vimc: skip .s_stream() for stopped entities
https://notcve.org/view.php?id=CVE-2025-22028
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: media: vimc: skip .s_stream() for stopped entities Syzbot reported [1] a warning prompted by a check in call_s_stream() that checks whether .s_stream() operation is warranted for unstarted or stopped subdevs. Add a simple fix in vimc_streamer_pipeline_terminate() ensuring that entities skip a call to .s_stream() unless they have been previously properly started. [1] Syzbot report: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 59... • https://git.kernel.org/stable/c/adc589d2a20808fb99d46a78175cd023f2040338 •
CVSS: 4.7EPSS: 0%CPEs: 6EXPL: 0CVE-2025-22027 – media: streamzap: fix race between device disconnection and urb callback
https://notcve.org/view.php?id=CVE-2025-22027
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: media: streamzap: fix race between device disconnection and urb callback Syzkaller has reported a general protection fault at function ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer dereference of dev->raw pointer, even though it is checked for NULL in the same function, which means there is a race condition. It occurs due to the incorrect order of actions in the streamzap_disconnect() function: rc_unregister_devic... • https://git.kernel.org/stable/c/8e9e60640067858e8036d4d43bbf725c60613359 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2025-22026 – nfsd: don't ignore the return code of svc_proc_register()
https://notcve.org/view.php?id=CVE-2025-22026
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail i... • https://git.kernel.org/stable/c/9d9456185fd5f1891c74354ee297f19538141ead •
CVSS: 5.6EPSS: 0%CPEs: 8EXPL: 0CVE-2025-22025 – nfsd: put dl_stid if fail to queue dl_recall
https://notcve.org/view.php?id=CVE-2025-22025
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: nfsd: put dl_stid if fail to queue dl_recall Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we increment the reference count of dl_stid. We expect that after the corresponding work_struct is processed, the reference count of dl_stid will be decremented through the callback function nfsd4_cb_recall_release. However, if the call to nfsd4_run_cb fails, the incremented reference count of dl_stid will not be decremented corre... • https://git.kernel.org/stable/c/b874cdef4e67e5150e07eff0eae1cbb21fb92da1 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-58097 – wifi: ath11k: fix RCU stall while reaping monitor destination ring
https://notcve.org/view.php?id=CVE-2024-58097
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix RCU stall while reaping monitor destination ring While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id. However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash. kernel log: ath11k_pci 0000:58:00.0: data msdu_po... • https://git.kernel.org/stable/c/d5c65159f2895379e11ca13f62feabe93278985d •
CVSS: 7.1EPSS: 0%CPEs: 2EXPL: 0CVE-2024-58096 – wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode
https://notcve.org/view.php?id=CVE-2024-58096
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath... • https://git.kernel.org/stable/c/d5c65159f2895379e11ca13f62feabe93278985d •
CVSS: 7.1EPSS: 0%CPEs: 2EXPL: 0CVE-2024-58095 – jfs: add check read-only before txBeginAnon() call
https://notcve.org/view.php?id=CVE-2024-58095
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •
CVSS: 7.1EPSS: 0%CPEs: 2EXPL: 0CVE-2024-58094 – jfs: add check read-only before truncation in jfs_truncate_nolock()
https://notcve.org/view.php?id=CVE-2024-58094
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for "read-only" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the functio... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •