[LTS 9.4] CVE-2025-22113, CVE-2025-22121 #577
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jira VULN-65381 cve-pre CVE-2025-22121 commit-author Ye Bin <[email protected]> commit 69f3a30 Introduce ITAIL helper to get the bound of xattr in inode. Signed-off-by: Ye Bin <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> (cherry picked from commit 69f3a30) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-65381 cve CVE-2025-22121 commit-author Ye Bin <[email protected]> commit 5701875 There's issue as follows: BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Above issue happens as ext4_xattr_delete_inode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattr_check_inode() check if xattr if valid in inode. In fact, we can directly verify in ext4_iget_extra_inode(), so that there is no divergent verification. Fixes: e50e512 ("ext4: xattr-in-inode support") Signed-off-by: Ye Bin <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> (cherry picked from commit 5701875) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-65358 cve-pre CVE-2025-22113 commit-author Theodore Ts'o <[email protected]> commit bb15cea upstream-diff | Ignored the changes to the `ext4_maybe_update_superblock()' function introduced by ff0722d which is missing from ciqlts9_4 history and is not functionally neutral. The most common use that s_error_work will get scheduled is now the periodic update of the superblock. So rename it to s_sb_upd_work. Also rename the function flush_stashed_error_work() to update_super_work(). Signed-off-by: Theodore Ts'o <[email protected]> (cherry picked from commit bb15cea) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-65358 cve-pre CVE-2025-22113 commit-author Ojaswin Mujoo <[email protected]> commit 5a02a62 Define an ext4 wrapper over jbd2_journal_destroy to make sure we have consistent behavior during journal destruction. This will also come useful in the next patch where we add some ext4 specific logic in the destroy path. Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Baokun Li <[email protected]> Signed-off-by: Ojaswin Mujoo <[email protected]> Link: https://patch.msgid.link/c3ba78c5c419757e6d5f2d8ebb4a8ce9d21da86a.1742279837.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <[email protected]> (cherry picked from commit 5a02a62) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-65358 cve CVE-2025-22113 commit-author Ojaswin Mujoo <[email protected]> commit ce2f26e Presently we always BUG_ON if trying to start a transaction on a journal marked with JBD2_UNMOUNT, since this should never happen. However, while ltp running stress tests, it was observed that in case of some error handling paths, it is possible for update_super_work to start a transaction after the journal is destroyed eg: (umount) ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT) Hence, introduce a new mount flag to indicate journal is destroying and only do a journaled (and deferred) update of sb if this flag is not set. Otherwise, just fallback to an un-journaled commit. Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updates This sequence is important as it ensures that, after this point, there is no sb update that might be journaled so it is safe to update the sb outside the journal. (To avoid race discussed in 2d01ddc) Also, we don't need a similar check in ext4_grp_locked_error since it is only called from mballoc and AFAICT it would be always valid to schedule work here. Fixes: 2d01ddc ("ext4: save error info to sb through journal if available") Reported-by: Mahesh Kumar <[email protected]> Signed-off-by: Ojaswin Mujoo <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/9613c465d6ff00cd315602f99283d5f24018c3f7.1742279837.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <[email protected]> (cherry picked from commit ce2f26e) Signed-off-by: Marcin Wcisło <[email protected]>
PlaidCat
requested review from
PlaidCat,
bmastbergen,
kerneltoast,
shreeya-patel98 and
thefossguy-ciq
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[LTS 9.4]
CVE-2025-22121 VULN-65381
CVE-2025-22113 VULN-65358
Commits
CVE-2025-22121
7e3df38:
18ee55a:
The mainline fix 5701875 conflicts without 69f3a30. The cve-pre is a previous commit right before 5701875 in kernel's history, in fact they were commited at the same time and have the same author, suggesting that it was a single solution split into two commits to keep their scope atomized.
CVE-2025-22113
73fc46f:
176f3e9:
4f815fb:
Naive cherry-picking mainline fix ce2f26e resulted in conflicts in all edited places of the modified files
fs/ext4/ext4.h,fs/ext4/ext4_jbd2.h,fs/ext4/super.c.Commit 5a02a62 introduces the function
ext4_journal_destroy(…)which is one of the subjects of change in the fix ce2f26e. The function doesn't introduce any new functionality not present before, only captures a recurring pattern in thefs/ext4/super.cfile of destroying a sb journal object and nulling out its pointer afterwards. Adding it prevents conflicts in thefs/ext4/super.c.Commit bb15cea is similarly functionally neutral with its symbols renaming change. Having the
ext4_sb_infostruct's fields_error_workrenamed tos_sb_upd_workprevents conflicts in thefs/ext4/super.cfile.Commit ff0722d was required to have the bb15cea cherry-picked cleanly, as the latter was renaming the
s_error_worksymbol also in theext4_maybe_update_superblock(…)function introduced by the former. It provides a simple mechanism to keep the disk superblock updated and the kilobytes written counter more precise as a result (see https://www.spinics.net/lists/linux-ext4/msg85865.html for the best description of the issue). Although it's small and local, present in the mainline for two years without major changes (thus stable), providing a fix for what seems to be a bug, not a feature, and allows for cherry-picking the required bb15cea cleanly, it was decided not to pick it, as that would require pulling in its bugfix ee6a12d too, increasing the solution complexity of a part which arguably already shouldn't be picked anyway due to its functional non-neutrality. The bb15cea cherry-picking conflict was resolved manually by ignoring the introduction ofext4_maybe_update_superblock(…)function.The codebase prepared in such a way still conflicted due to ce2f26e not expecting the
EXT4_MF_FS_ABORTEDin the enum which it modified by adding theEXT4_MF_JOURNAL_DESTROYcase. TheEXT4_MF_FS_ABORTEDwas removed in 9525798 which wasn't backported tociqlts9_4. Similarly to ff0722d it was considered to be included in the solution despite diverging functionally from the fix, but it required its own additional prerequisites which would have complicated the solution beyond acceptable limit. The conflict was resolved manually by simply keeping theEXT4_MF_FS_ABORTEDmember. Theupstream-diffwas omitted as this resolution didn't modify the upstream change in any way (the delta is the same) but dealt with the cherry-picking technicalities.kABI check: passed
Boot test: passed
boot-test.log
Kselftests: passed relative
Reference
kselftests–ciqlts9_4–run1.log
Patch
kselftests–ciqlts9_4-CVE-batch-4–run1.log
Comparison
The tests results are the same for the reference and the patch.