Page 117 of 3563 results (0.010 seconds)

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

30 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: IB/core: Implement a limit on UMAD receive List The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such... • https://git.kernel.org/stable/c/1288cf1cceb0e6df276e182f5412370fb4169bcb •

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

30 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: vhost_task: Handle SIGKILL by flushing work and exiting Instead of lingering until the device is closed, this has us handle SIGKILL by: 1. marking the worker as killed so we no longer try to use it with new virtqueues and new flush operations. 2. setting the virtqueue to worker mapping so no new works are queued. 3. running all the exiting works. In the Linux kernel, the following vulnerability has been resolved: vhost_task: Handle SIGKILL ... • https://git.kernel.org/stable/c/abe067dc3a662eef7d5cddbbc41ed50a0b68b0af •

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

30 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: mm: avoid overflows in dirty throttling logic The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes inter... • https://git.kernel.org/stable/c/2b2d2b8766db028bd827af34075f221ae9e9efff • CWE-190: Integer Overflow or Wraparound •

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

30 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: leds: mlxreg: Use devm_mutex_init() for mutex initialization In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. In the Linux kernel, the following vulnerability has be... • https://git.kernel.org/stable/c/618c6ce83471ab4f7ac744d27b9d03af173bc141 •

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

30 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: jffs2: Fix potential illegal address access in jffs2_free_inode During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.6... • https://git.kernel.org/stable/c/b6c8b3e31eb88c85094d848a0bd8b4bafe67e4d8 •

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

30 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix inode number range checks Patch series "nilfs2: fix potential issues related to reserved inodes". This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default... • https://git.kernel.org/stable/c/57235c3c88bb430043728d0d02f44a4efe386476 •

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

30 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: nilfs2: add missing check for inode numbers on directory entries Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile... • https://git.kernel.org/stable/c/c33c2b0d92aa1c2262d999b2598ad6fbd53bd479 •

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

29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: crypto: ecdh - explicitly zeroize private_key private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the enti... • https://git.kernel.org/stable/c/39173b04abda87872b43c331468a4a14f8f05ce8 •

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

29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: ALSA: emux: improve patch ioctl data validation In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did. In the Linux kernel, the following vulnerability has been resolved: ALSA: emux: improve patch ioctl data validation In load_data(), make the validation of an... • https://git.kernel.org/stable/c/40d7def67841343c10f8642a41031fecbb248bab •

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

29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: x86: stop playing stack games in profile_pc() The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid. Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity... • https://git.kernel.org/stable/c/65ebdde16e7f5da99dbf8a548fb635837d78384e • CWE-125: Out-of-bounds Read •