Page 51 of 2812 results (0.010 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix state management in error path of log writing function After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling. First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang. Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping. Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared. • https://git.kernel.org/stable/c/a694291a6211537189c6080f77f63cdabfc9b63e https://git.kernel.org/stable/c/40a2757de2c376ef8a08d9ee9c81e77f3c750adf https://git.kernel.org/stable/c/036441e8438b29111fa75008f0ce305fb4e83c0a https://git.kernel.org/stable/c/efdde00d4a1ef10bb71e09ebc67823a3d3ad725b https://git.kernel.org/stable/c/3e349d7191f0688fc9808ef24fd4e4b4ef5ca876 https://git.kernel.org/stable/c/30562eff4a6dd35c4b5be9699ef61ad9f5f20a06 https://git.kernel.org/stable/c/0a1a961bde4351dc047ffdeb2f1311ca16a700cc https://git.kernel.org/stable/c/74866c16ea2183f52925fa5d76061a1fe •

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

In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later. If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path. • https://git.kernel.org/stable/c/0f27f4f445390cb7f73d4209cb2bf32834dc53da https://git.kernel.org/stable/c/99418ec776a39609f50934720419e0b464ca2283 https://git.kernel.org/stable/c/ad5ee9feebc2eb8cfc76ed74a2d6e55343b0e169 https://git.kernel.org/stable/c/ebeff038744c498a036e7a92eb8e433ae0a386d7 https://git.kernel.org/stable/c/d942e855324a60107025c116245095632476613e https://git.kernel.org/stable/c/0f078f8ca93b28a34e20bd050f12cd4efeee7c0f https://git.kernel.org/stable/c/b2f11c6f3e1fc60742673b8675c95b78447f3dae https://access.redhat.com/security/cve/CVE-2024-47668 •

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

In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf • https://git.kernel.org/stable/c/cfb006e185f64edbbdf7869eac352442bc76b8f6 https://git.kernel.org/stable/c/ebbdbbc580c1695dec283d0ba6448729dc993246 https://git.kernel.org/stable/c/135843c351c08df72bdd4b4ebea53c8052a76881 https://git.kernel.org/stable/c/af218c803fe298ddf00abef331aa526b20d7ea61 https://git.kernel.org/stable/c/576d0fb6f8d4bd4695e70eee173a1b9c7bae9572 https://git.kernel.org/stable/c/dd47051c76c8acd8cb983f01b4d1265da29cb66a https://git.kernel.org/stable/c/86f271f22bbb6391410a07e08d6ca3757fda01fa •

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

In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Set phy->enable_completion only when we wait for it pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash. • https://git.kernel.org/stable/c/7b1d779647afaea9185fa2f150b1721e7c1aae89 https://git.kernel.org/stable/c/f14d3e1aa613311c744af32d75125e95fc8ffb84 https://git.kernel.org/stable/c/e4f949ef1516c0d74745ee54a0f4882c1f6c7aea •

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

In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup Definitely condition dma_get_cache_alignment * defined value > 256 during driver initialization is not reason to BUG_ON(). Turn that to graceful error out with -EINVAL. • https://git.kernel.org/stable/c/cacb76df247a7cd842ff29755a523b1cba6c0508 https://git.kernel.org/stable/c/2666085335bdfedf90d91f4071490ad3980be785 https://git.kernel.org/stable/c/5a022269abb22809f2a174b90f200fc4b9526058 https://git.kernel.org/stable/c/e2d14bfda9eb5393f8a17008afe2aa7fe0a29815 https://git.kernel.org/stable/c/8a2be2f1db268ec735419e53ef04ca039fc027dc •