In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ext4: use fsdata to track inline data write state and fix race<\/p>\n
Instead of checking the live inode state (ext4_has_inline_data(inode)
\nand ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the
\nwrite_end handlers, use the fsdata parameter of the address space
\noperations to explicitly pass down the state in which write_begin
\nprepared the write.<\/p>\n
A concurrent thread (such as ext4_page_mkwrite()) can convert the
\ninline data to an extent between write_begin and write_end. If this
\nhappens, the write_end handlers would previously miss the inline
\nwrite_end path and fall through to extent-based write_end logic.
\nHowever, since block buffers were never allocated in write_begin,
\nthis resulted in NULL pointer dereferences or data loss because
\nfolio_buffers(folio) was NULL.<\/p>\n
Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating
\nfsdata as bitwise flags rather than mutually exclusive enums to keep
\nstates of the write path independent. Communicate this state via
\nfsdata:
\n1) ext4_write_begin() and ext4_da_write_begin() set the
\n EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline
\n write is successfully prepared.
\n2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit
\n to safely handle VFS retries (where generic_perform_write() bypasses
\n the fsdata initialization on its retry jump).
\n3) The write_end handlers perform a bitwise AND to check if the
\n EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end
\n helper accordingly.<\/p>\n
Furthermore, during a buffered write, ext4_write_inline_data_end()
\nacquires the xattr lock after preparing the write. If a concurrent
\npage fault (ext4_page_mkwrite()) converts the inline data to an extent
\nafter the write_end handlers check the state but before
\next4_write_inline_data_end() acquires the xattr write lock, the
\nsubsequent check will trigger a kernel panic via
\nBUG_ON(!ext4_has_inline_data(inode)).<\/p>\n
To keep git history working and bisectability clean, replace the
\nBUG_ON check in ext4_write_inline_data_end() with a graceful error-
\nhandling retry path in this same commit. If the inline data is cleared
\nafter locking the xattr, we safely release all resources (releasing
\niloc.bh, unlocking\/putting the folio, stopping the active journal
\ntransaction handle) and return 0 (VFS retry) to let the generic write
\npath retry the operation safely.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ext4: use fsdata to track inline data write state and fix race<\/p>\n
Instead of checking the live inode state (ext4_has_inline_data(inod<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-25869","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/25869","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=25869"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=25869"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=25869"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}