Page 44 of 4926 results (0.006 seconds)

CVSS: 6.1EPSS: 0%CPEs: 6EXPL: 0

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: arm64: csum: Fix OoB access in IP checksum code for negative lengths Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length calls") added an early return for zero-length input, syzkaller has popped up with an example of a _negative_ length which causes an undefined shift and an out-of-bounds read: | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | Read of size 4294966928 at addr ffff0000d7ac0... • https://git.kernel.org/stable/c/5777eaed566a1d63e344d3dd8f2b5e33be20643e • CWE-839: Numeric Range Comparison Without Minimum Check •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probe Smatch reports: drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe() warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516. timer_baseaddr may have the problem of not being released after use, I replaced it with the devm_of_iomap() function and added the clk_put() function to cleanup the "clk_ce" and "clk_cs". In the Linux kernel, the following ... • https://git.kernel.org/stable/c/e932900a3279b5dbb6d8f43c7b369003620e137c •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: mfd: pcf50633-adc: Fix potential memleak in pcf50633_adc_async_read() `req` is allocated in pcf50633_adc_async_read(), but adc_enqueue_request() could fail to insert the `req` into queue. We need to check the return value and free it in the case of failure. In the Linux kernel, the following vulnerability has been resolved: mfd: pcf50633-adc: Fix potential memleak in pcf50633_adc_async_read() `req` is allocated in pcf50633_adc_async_read(),... • https://git.kernel.org/stable/c/08c3e06a5eb27d43b712adef18379f8464425e71 •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend sdma_v4_0_ip is shared on a few asics, but in sdma_v4_0_hw_fini, driver unconditionally disables ecc_irq which is only enabled on those asics enabling sdma ecc. This will introduce a warning in suspend cycle on those chips with sdma ip v4.0, while without sdma ecc. So this patch correct this. [ 7283.166354] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu] [ 7283.167001] RS... • https://git.kernel.org/stable/c/3decf3a750a924362bf4e2680dd3b07242fe56e8 •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: md: raid1: fix potential OOB in raid1_remove_disk() If rddev->raid_disk is greater than mddev->raid_disks, there will be an out-of-bounds in raid1_remove_disk(). We have already found similar reports as follows: 1) commit d17f744e883b ("md-raid10: fix KASAN warning") 2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk") Fix this bug by checking whether the "number" variable is valid. In the Linux kernel, the following v... • https://git.kernel.org/stable/c/beedf40f73939f248c81802eda08a2a8148ea13e • CWE-125: Out-of-bounds Read •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: serial: arc_uart: fix of_iomap leak in `arc_serial_probe` Smatch reports: drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn: 'port->membase' from of_iomap() not released on lines: 631. In arc_serial_probe(), if uart_add_one_port() fails, port->membase is not released, which would cause a resource leak. To fix this, I replace of_iomap with devm_platform_ioremap_resource. In the Linux kernel, the following vulnerability has been resol... • https://git.kernel.org/stable/c/8dbe1d5e09a7faec8d22cadcc1011acab8fa6e2a •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not swap cpu_buffer during resize process When ring_buffer_swap_cpu was called during resize process, the cpu buffer was swapped in the middle, resulting in incorrect state. Continuing to run in the wrong state will result in oops. This issue can be easily reproduced using the following two scripts: /tmp # cat test1.sh //#! /bin/sh for i in `seq 0 100000` do echo 2000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 echo... • https://git.kernel.org/stable/c/66a3b2a121386702663065d5c9e5a33c03d3f4a2 •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback() Fix a stack-out-of-bounds write that occurs in a WMI response callback function that is called after a timeout occurs in ath9k_wmi_cmd(). The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer that could no longer be valid when a timeout occurs. Set wmi->last_seq_id to 0 when a timeout occurred. Found by a modified version of syzkaller. BUG: KASAN: s... • https://git.kernel.org/stable/c/fb9987d0f748c983bb795a86f47522313f701a08 • CWE-787: Out-of-bounds Write •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: net: fix skb leak in __skb_tstamp_tx() Commit 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.") added a call to skb_orphan_frags_rx() to fix leaks with zerocopy skbs. But it ended up adding a leak of its own. When skb_orphan_frags_rx() fails, the function just returns, leaking the skb it just cloned. Free it before returning. This bug was discovered and resolved using Coverity Static Analysis Security Testing... • https://git.kernel.org/stable/c/281072fb2a7294cde7acbf5375b879f40a8001b7 • CWE-772: Missing Release of Resource after Effective Lifetime •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex Apparently the hex passphrase mechanism does not work on newer chips/firmware (e.g. BCM4387). It seems there was a simple way of passing it in binary all along, so use that and avoid the hexification. OpenBSD has been doing it like this from the beginning, so this should work on all chips. Also clear the structure before setting the PMK. • https://git.kernel.org/stable/c/1687845eb8f37360a9ee849a3587ab659b090773 •