Page 5 of 6875 results (0.007 seconds)

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Move packet length check to prevent kernel panic in skb_pull Packet length check needs to be located after size and align_count calculation to prevent kernel panic in skb_pull() in case rx_cmd_a & RX_CMD_A_RED evaluates to true. In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Move packet length check to prevent kernel panic in skb_pull Packet length check needs to be located after ... • https://git.kernel.org/stable/c/43ffe6caccc7a1bb9d7442fbab521efbf6c1378c •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails syzbot reported a warning[1] where the bond device itself is a slave and we try to enslave a non-ethernet device as the first slave which fails but then in the error path when ether_setup() restores the bond device it also clears all flags. In my previous fix[2] I restored the IFF_MASTER flag, but I didn't consider the case that the bond device itself might also be a slav... • https://git.kernel.org/stable/c/7d5cd2ce5292b45e555de776cb9e72975a07460d •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ice: xsk: disable txq irq before flushing hw ice_qp_dis() intends to stop a given queue pair that is a target of xsk pool attach/detach. One of the steps is to disable interrupts on these queues. It currently is broken in a way that txq irq is turned off *after* HW flush which in turn takes no effect. ice_qp_dis(): -> ice_qvec_dis_irq() --> disable rxq irq --> flush hw -> ice_vsi_stop_tx_ring() -->disable txq irq Below splat can be triggere... • https://git.kernel.org/stable/c/2d4238f5569722197612656163d824098208519c •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ext4: zero i_disksize when initializing the bootloader inode If the boot loader inode has never been used before, the EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the i_size to 0. However, if the "never before used" boot loader has a non-zero i_size, then i_disksize will be non-zero, and the inconsistency between i_size and i_disksize can trigger a kernel warning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID:... • https://git.kernel.org/stable/c/d6c1447e483c05dbcfb3ff77ac04237a82070b8c •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ext4: fix WARNING in ext4_update_inline_data Syzbot found the following issue: EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none. fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni" fscrypt: AES-256-XTS using implementation "xts-aes-aesni" ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525... • https://git.kernel.org/stable/c/c5aa102b433b1890e1ccaa40c06826c77dda1665 •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: firmware: xilinx: don't make a sleepable memory allocation from an atomic context The following issue was discovered using lockdep: [ 6.691371] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:209 [ 6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0 [ 6.702431] 2 locks held by swapper/0/1: [ 6.706300] #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x4... • https://git.kernel.org/stable/c/acfdd18591eaac25446e976a0c0d190f8b3dbfb1 •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: media: rc: gpio-ir-recv: add remove function In case runtime PM is enabled, do runtime PM clean up to remove cpu latency qos request, otherwise driver removal may have below kernel dump: [ 19.463299] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048 [ 19.472161] Mem abort info: [ 19.474985] ESR = 0x0000000096000004 [ 19.478754] EC = 0x25: DABT (current EL), IL = 32 bits [ 19.484081] SET = 0, FnV = 0 [ 19.4... • https://git.kernel.org/stable/c/a5c140d88a69eb43de2a030f1d7ff7b16bff3b1a •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: powerpc/iommu: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. In the Linux kernel, the following vulnerability has been resolved: powerpc/iommu: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the ... • https://git.kernel.org/stable/c/e3a62a35f903fd8be5b44542fe3901ec45f16757 •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: interconnect: fix mem leak when freeing nodes The node link array is allocated when adding links to a node but is not deallocated when nodes are destroyed. In the Linux kernel, the following vulnerability has been resolved: interconnect: fix mem leak when freeing nodes The node link array is allocated when adding links to a node but is not deallocated when nodes are destroyed. • https://git.kernel.org/stable/c/11f1ceca7031deefc1a34236ab7b94360016b71d •

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

02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix a NULL pointer dereference The LRU mechanism may look up a resource in the process of being removed from an object. The locking rules here are a bit unclear but it looks currently like res->bo assignment is protected by the LRU lock, whereas bo->resource is protected by the object lock, while *clearing* of bo->resource is also protected by the LRU lock. This means that if we check that bo->resource points to the LRU resource un... • https://git.kernel.org/stable/c/6a9b028994025f5033f10d1da30b29dfdc713384 •