Page 3 of 1433 results (0.001 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on. • https://git.kernel.org/stable/c/1bec6782a25c9b92c203ea7a1b3e3dc6a468cbc4 https://git.kernel.org/stable/c/d984648e428bf88cbd94ebe346c73632cb92fffb https://git.kernel.org/stable/c/bdbc96c23197d773a7d1bf03e4f11de593b0ff28 https://git.kernel.org/stable/c/9bc18bb476e50e32e5d08f2734d63d63e0fa528c https://git.kernel.org/stable/c/8e9c0f500b42216ef930f5c0d1703989a451913d https://git.kernel.org/stable/c/50793801fc7f6d08def48754fb0f0706b0cfc394 •

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

In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ] • https://git.kernel.org/stable/c/94e8c988468dafde1d2bfe0532a60a3117f6394b https://git.kernel.org/stable/c/f812ca13a0d3e3aa418da36b66ca40df0d6f9e60 https://git.kernel.org/stable/c/8ad28208be7bbe748e90442c45963ddbef0fd1e2 https://git.kernel.org/stable/c/20cde05aa8bcd7a5ff36a609d813189b7cdbe692 https://git.kernel.org/stable/c/60949b7b805424f21326b450ca4f1806c06d982e https://git.kernel.org/stable/c/82cee12ada68dfd438c7faca152dbfe042868743 https://git.kernel.org/stable/c/c46d6b02588000c27b7b869388c2c0278bd0d173 https://git.kernel.org/stable/c/23039b4aaf1e82e0feea1060834d4ec34 •

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

In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region. • https://git.kernel.org/stable/c/22cdf3be7d34f61a91b9e2966fec3a29f3871398 https://git.kernel.org/stable/c/809f9b419c75f8042c58434d2bfe849140643e9d https://git.kernel.org/stable/c/556bdf27c2dd5c74a9caacbe524b943a6cd42d99 •

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

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off. • https://git.kernel.org/stable/c/e5ae7859008688626b4d2fa6139eeaa08e255053 https://git.kernel.org/stable/c/1b6bc5f7212181093b6c5310eea216fc09c721a9 https://git.kernel.org/stable/c/5f21e3e60982cd7353998b4f59f052134fd47d64 https://git.kernel.org/stable/c/4a4727bc582832f354e0d3d49838a401a28ae25e https://git.kernel.org/stable/c/9931122d04c6d431b2c11b5bb7b10f28584067f0 •

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

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check • https://git.kernel.org/stable/c/e91fbb21f248bdd8140f343dac32b77b9bc10fec https://git.kernel.org/stable/c/2fcae4c2014a40c8ae0fc3d8cca3ba9e168308de https://git.kernel.org/stable/c/c4a8ba334262e9a5c158d618a4820e1b9c12495c •