Page 5 of 4205 results (0.007 seconds)

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait While performing fast composition switch, there is a possibility that the process of ffs_ep0_write/ffs_ep0_read get into a race condition due to ep0req being freed up from functionfs_unbind. Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't bounded so it can go ahead and mark the ep0req... • https://git.kernel.org/stable/c/ddf8abd2599491cbad959c700b90ba72a5dce8d0 • CWE-416: Use After Free •

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix double increment of client_count in dma_chan_get() The first time dma_chan_get() is called for a channel the channel client_count is incorrectly incremented twice for public channels, first in balance_ref_count(), and again prior to returning. This results in an incorrect client count which will lead to the channel resources not being freed when they should be. A simple test of repeated module load and unload of async_tx on a... • https://git.kernel.org/stable/c/d2f4f99db3e9ec8b063cf2e45704e2bb95428317 • CWE-416: Use After Free •

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: w1: fix WARNING after calling w1_process() I got the following WARNING message while removing driver(ds2482): ------------[ cut here ]------------ do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire] WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0 CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307 RIP: 0010:__might_sleep+0x98/0xa0 Call Trace... • https://git.kernel.org/stable/c/3c52e4e627896b42152cc6ff98216c302932227e •

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: cpufreq: CPPC: Add u64 casts to avoid overflowing The fields of the _CPC object are unsigned 32-bits values. To avoid overflows while using _CPC's values, add 'u64' casts. In the Linux kernel, the following vulnerability has been resolved: cpufreq: CPPC: Add u64 casts to avoid overflowing The fields of the _CPC object are unsigned 32-bits values. To avoid overflows while using _CPC's values, add 'u64' casts. • https://git.kernel.org/stable/c/7d596bbc66a52ff2c7a83d7e0ee840cb07e2a045 •

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: i2c: designware: use casting of u64 in clock multiplication to avoid overflow In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow by depending on the values of the given parameters including the ic_clk. For example in our use case where ic_clk is larger than one million, multiplication of ic_clk * 4700 will result in 32 bit overflow. Add cast of u64 to the calculation to avoid multiplication overflow, and use the correspo... • https://git.kernel.org/stable/c/2373f6b9744d5373b886f3ce1a985193cca0a356 •

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: fix potential integer overflow on shift of a int The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then passed as a 64 bit function argument. In the case where i is 32 or more this can lead to an overflow. Avoid this by shifting using the BIT_ULL macro instead. In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: fix potential integer overflow on shift of a in... • https://git.kernel.org/stable/c/d8a6a443ff0aea5893f0a7f2726973b496b76420 •

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: erofs/zmap.c: Fix incorrect offset calculation Effective offset to add to length was being incorrectly calculated, which resulted in iomap->length being set to 0, triggering a WARN_ON in iomap_iter_done(). Fix that, and describe it in comments. This was reported as a crash by syzbot under an issue about a warning encountered in iomap_iter_done(), but unrelated to erofs. C reproducer: https://syzkaller.appspot.com/text?tag=ReproC&x=1037a6b28... • https://git.kernel.org/stable/c/2144859229c1e74f52d3ea067338d314a83a8afb •

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init If the function sdma_load_context() fails, the sdma_desc will be freed, but the allocated desc->bd is forgot to be freed. We already met the sdma_load_context() failure case and the log as below: [ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready ... In this case, the desc->bd will not be freed without this change. In the Linux kernel, the follo... • https://git.kernel.org/stable/c/80ee99e52936b2c04cc37b17a14b2ae2f9d282ac •

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: ovl: Use "buf" flexible array for memcpy() destination The "buf" flexible array needs to be the memcpy() destination to avoid false positive run-time warning from the recent FORTIFY_SOURCE hardening: memcpy: detected field-spanning write (size 93) of single field "&fh->fb" at fs/overlayfs/export.c:799 (size 21) In the Linux kernel, the following vulnerability has been resolved: ovl: Use "buf" flexible array for memcpy() destination The "buf... • https://git.kernel.org/stable/c/a77141a06367825d639ac51b04703d551163e36c •

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

27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: f2fs: initialize locks earlier in f2fs_fill_super() syzbot is reporting lockdep warning at f2fs_handle_error() [1], for spin_lock(&sbi->error_lock) is called before spin_lock_init() is called. For safe locking in error handling, move initialization of locks (and obvious structures) in f2fs_fill_super() to immediately after memory allocation. In the Linux kernel, the following vulnerability has been resolved: f2fs: initialize locks earlier i... • https://git.kernel.org/stable/c/ddeff03bb33810fcf2f0c18e03d099cf0aacda62 •