Page 29 of 2837 results (0.020 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE. • https://git.kernel.org/stable/c/0c4dcd602817502bb3dced7a834a13ef717d65a4 https://git.kernel.org/stable/c/df6fed0a2a1a5e57f033bca40dc316b18e0d0ce6 https://git.kernel.org/stable/c/de5857fa7bcc9a496a914c7e21390be873109f26 https://git.kernel.org/stable/c/ea701c1849e7250ea41a4f7493e0a5f136c1d47e https://git.kernel.org/stable/c/87cb3b0054e53e0155b630bdf8fb714ded62565f https://git.kernel.org/stable/c/daac56dd98e1ba814c878ac0acd482a37f2ab94b https://git.kernel.org/stable/c/7988bdbbb85ac85a847baf09879edcd0f70521dc •

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

In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix reader locking when changing the sub buffer order The function ring_buffer_subbuf_order_set() updates each ring_buffer_per_cpu and installs new sub buffers that match the requested page order. This operation may be invoked concurrently with readers that rely on some of the modified data, such as the head bit (RB_PAGE_HEAD), or the ring_buffer_per_cpu.pages and reader_page pointers. However, no exclusive access is acquired by ring_buffer_subbuf_order_set(). Modifying the mentioned data while a reader also operates on them can then result in incorrect memory access and various crashes. Fix the problem by taking the reader_lock when updating a specific ring_buffer_per_cpu in ring_buffer_subbuf_order_set(). • https://git.kernel.org/stable/c/8e7b58c27b3c567316a51079b375b846f9223bba https://git.kernel.org/stable/c/a569290525a05162d5dd26d9845591eaf46e5802 https://git.kernel.org/stable/c/09661f75e75cb6c1d2d8326a70c311d46729235f •

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

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init The loop responsible for allocating up to MTK_FQ_DMA_LENGTH buffers must only touch as many descriptors, otherwise it ends up corrupting unrelated memory. Fix the loop iteration count accordingly. • https://git.kernel.org/stable/c/c57e558194430d10d5e5f4acd8a8655b68dade13 https://git.kernel.org/stable/c/6f50d0bc1bbd45ce2a6d8f378daa00e56c198e9e https://git.kernel.org/stable/c/68cd084e3ec1512cd383cb3e9cf0ab7ab413724c https://git.kernel.org/stable/c/88806efc034a9830f483963326b99930ad519af1 •

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

In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/826b5de90c0bca4e9de6231da9e1730480621588 https://git.kernel.org/stable/c/d575414361630b8b0523912532fcd7c79e43468c https://git.kernel.org/stable/c/5e431f85c87bbffd93a9830d5a576586f9855291 https://git.kernel.org/stable/c/7d4eb9e22131ec154e638cbd56629195c9bcbe9a https://git.kernel.org/stable/c/d2826873db70a6719cdd9212a6739f3e6234cfc4 https://git.kernel.org/stable/c/4bdc21506f12b2d432b1f2667e5ff4c75eee58e3 https://git.kernel.org/stable/c/3452d39c4704aa12504e4190298c721fb01083c3 https://git.kernel.org/stable/c/72cafe63b35d06b5cfbaf807e90ae6579 •

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

In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix address emission with tag-based KASAN enabled When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image struct on the stack is passed during the size calculation pass and an address on the heap is passed during code generation. This may cause a heap buffer overflow if the heap address is tagged because emit_a64_mov_i64() will emit longer code than it did during the size calculation pass. The same problem could occur without tag-based KASAN if one of the 16-bit words of the stack address happened to be all-ones during the size calculation pass. Fix the problem by assuming the worst case (4 instructions) when calculating the size of the bpf_tramp_image address emission. • https://git.kernel.org/stable/c/19d3c179a37730caf600a97fed3794feac2b197b https://git.kernel.org/stable/c/6d218fcc707d6b2c3616b6cd24b948fd4825cfec https://git.kernel.org/stable/c/7db1a2121f3c7903b8e397392beec563c3d00950 https://git.kernel.org/stable/c/a552e2ef5fd1a6c78267cd4ec5a9b49aa11bbb1c •