Page 8 of 6687 results (0.009 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances. • https://git.kernel.org/stable/c/0c4dcd602817502bb3dced7a834a13ef717d65a4 https://git.kernel.org/stable/c/dbe51dd516e6d4e655f31c8a1cbc050dde7ba97b https://git.kernel.org/stable/c/322a19baaaa25a1fe8ce9fceaed9409ad847844c https://git.kernel.org/stable/c/76dd679c3b148d23f72dcf6c3cde3d5f746b2c07 https://git.kernel.org/stable/c/c71957271f2e8133a6aa82001c2fa671d5008129 https://git.kernel.org/stable/c/ba9045887b435a4c5551245ae034b8791b4e4aaa https://git.kernel.org/stable/c/c5c1ae73b7741fa3b58e6e001b407825bb971225 •

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: 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: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together. • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/bb857ae1efd3138c653239ed1e7aef14e1242c81 https://git.kernel.org/stable/c/b4b3dc9e7e604be98a222e9f941f5e93798ca475 https://git.kernel.org/stable/c/c1d0476885d708a932980b0f28cd90d9bd71db39 https://git.kernel.org/stable/c/edf8146057264191d5bfe5b91773f13d936dadd3 https://git.kernel.org/stable/c/270a6f9df35fa2aea01ec23770dc9b3fc9a12989 https://git.kernel.org/stable/c/9698088ac7704e260f492d9c254e29ed7dd8729a https://git.kernel.org/stable/c/efa810b15a25531cbc2f527330947b9fe •

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

In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db) • https://git.kernel.org/stable/c/74d2aacbe84042d89f572a3112a146fca05bfcb1 https://git.kernel.org/stable/c/df75c78bfeff99f9b4815c3e79e2b1b1e34fe264 https://git.kernel.org/stable/c/fda5dc80121b12871dc343ab37e0c3f0d138825d https://git.kernel.org/stable/c/c3cd27d85f0778f4ec07384d7516b33153759b8e https://git.kernel.org/stable/c/1a235af0216411a32ab4db54f7bd19020b46c86d https://git.kernel.org/stable/c/68801730ebb9393460b30cd3885e407f15da27a9 https://git.kernel.org/stable/c/28127dba64d8ae1a0b737b973d6d029908599611 •