Page 9 of 6630 results (0.010 seconds)

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential oops in cifs_oplock_break With deferred close we can have closes that race with lease breaks, and so with the current checks for whether to send the lease response, oplock_response(), this can mean that an unmount (kill_sb) can occur just before we were checking if the tcon->ses is valid. See below: [Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs] [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 ... • https://git.kernel.org/stable/c/63fb45ddc491895c4b36664e0c2c3b548545ae93 •

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: net: macb: fix a memory corruption in extended buffer descriptor mode For quite some time we were chasing a bug which looked like a sudden permanent failure of networking and mmc on some of our devices. The bug was very sensitive to any software changes and even more to any kernel debug options. Finally we got a setup where the problem was reproducible with CONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma: [ 16.992082] -----... • https://git.kernel.org/stable/c/7b4296148066f19b5960127ba579e358df501c22 •

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: sh: dma: Fix DMA channel offset calculation Various SoCs of the SH3, SH4 and SH4A family, which use this driver, feature a differing number of DMA channels, which can be distributed between up to two DMAC modules. The existing implementation fails to correctly accommodate for all those variations, resulting in wrong channel offset calculations and leading to kernel panics. Rewrite dma_base_addr() in order to properly calculate channel offse... • https://git.kernel.org/stable/c/7f47c7189b3e8f19a589f77a3ad169d7b691b582 •

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Don't leak a resource on eviction error On eviction errors other than -EMULTIHOP we were leaking a resource. Fix. v2: - Avoid yet another goto (Andi Shyti) • https://git.kernel.org/stable/c/403797925768d9fa870f5b1ebcd20016b397083b •

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: set page extent mapped after read_folio in relocate_one_page One of the CI runs triggered the following panic assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 ------------[ cut here ]------------ kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=-... • https://git.kernel.org/stable/c/32443de3382be98c0a8b8f6f50d23da2e10c4117 •

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: Limit TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME to INT_MAX. syzkaller found zero division error [0] in div_s64_rem() called from get_cycle_time_elapsed(), where sched->cycle_time is the divisor. We have tests in parse_taprio_schedule() so that cycle_time will never be 0, and actually cycle_time is not 0 in get_cycle_time_elapsed(). The problem is that the types of divisor are different; cycle_time is s64, but the argument of div_s... • https://git.kernel.org/stable/c/4cfd5779bd6efe8c76b4494aec63a063be0d2ff2 •

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: ksmbd: avoid out of bounds access in decode_preauth_ctxt() Confirm that the accessed pneg_ctxt->HashAlgorithms address sits within the SMB request boundary; deassemble_neg_contexts() only checks that the eight byte smb2_neg_context header + (client controlled) DataLength are within the packet boundary, which is insufficient. Checking for sizeof(struct smb2_preauth_neg_context) is overkill given that the type currently assumes SMB311_SALT_SI... • https://git.kernel.org/stable/c/e2f34481b24db2fd634b5edb0a5bd0e4d38cc6e9 •

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Only send -ENOTCONN status if client driver is available For the STOP and RESET commands, only send the channel disconnect status -ENOTCONN if client driver is available. Otherwise, it will result in null pointer dereference. • https://git.kernel.org/stable/c/e827569062a804c67b51930ce83a4cb886113cb7 •

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add check for kmemdup Since the kmemdup may return NULL pointer, it should be better to add check for the return value in order to avoid NULL pointer dereference. • https://git.kernel.org/stable/c/b46acd6a6a627d876898e1c84d3f84902264b445 •

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

30 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf: Silence a warning in btf_type_id_size() syzbot reported a warning in [1] with the following stacktrace: WARNING: CPU: 0 PID: 5005 at kernel/bpf/btf.c:1988 btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... RIP: 0010:btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... Call Trace: map_check_btf kernel/bpf/syscall.c:1024 [inline] map_create+0x1157/0x1860 kernel/bpf/syscall.c:1198 __sys_bpf+0x127f/0x5420 kernel/bpf/syscall.c:... • https://git.kernel.org/stable/c/b5ea834dde6b6e7f75e51d5f66dac8cd7c97b5ef •