Page 362 of 5994 results (0.010 seconds)

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Prevent potential buffer overflow in map_hw_resources Adds a check in the map_hw_resources function to prevent a potential buffer overflow. The function was accessing arrays using an index that could potentially be greater than the size of the arrays, leading to a buffer overflow. Adds a check to ensure that the index is within the bounds of the arrays. If the index is out of bounds, an error message is printed and break it... • https://git.kernel.org/stable/c/7966f319c66d9468623c6a6a017ecbc0dd79be75 • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: drivers: perf: ctr_get_width function for legacy is not defined With parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n linux kernel crashes when you try perf record: $ perf record ls [ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 46.750199] Oops [#1] [ 46.750342] Modules linked in: [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2 [ 46.750906] Hardware name: ... • https://git.kernel.org/stable/c/cc4c07c89aada16229084eeb93895c95b7eabaa3 •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: riscv: Sparse-Memory/vmemmap out-of-bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments En el kernel de Linux, se res... • https://git.kernel.org/stable/c/d95f1a542c3df396137afa217ef9bd39cb8931ca •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between ordered extent completion and fiemap For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc). However by not locking the target extent rang... • https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KA... • https://git.kernel.org/stable/c/459aa660eb1d8ce67080da1983bb81d716aa5a69 •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of anonymous device after snapshot creation failure When creating a snapshot we may do a double free of an anonymous device in case there's an error committing the transaction. The second free may result in freeing an anonymous device number that was allocated by some other subsystem in the kernel or another btrfs filesystem. The steps that lead to this: 1) At ioctl.c:create_snapshot() we allocate an anonymous device ... • https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and ... • https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84 •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read There is chip (ls1028a) errata: The SoC may hang on 16 byte unaligned read transactions by QDMA. Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller. Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ).... • https://git.kernel.org/stable/c/b092529e0aa09829a6404424ce167bf3ce3235e2 •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: crypto: arm64/neonbs - fix out-of-bounds access on short input The bit-sliced implementation of AES-CTR operates on blocks of 128 bytes, and will fall back to the plain NEON version for tail blocks or inputs that are shorter than 128 bytes to begin with. It will call straight into the plain NEON asm helper, which performs all memory accesses in granules of 16 bytes (the size of a NEON register). For this reason, the associated plain NEON gl... • https://git.kernel.org/stable/c/fc074e130051015e39245a4241956ff122e2f465 •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: init irq after reg initialization Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi... • https://git.kernel.org/stable/c/b092529e0aa09829a6404424ce167bf3ce3235e2 •