[syzbot] [ocfs2?] [ext4?] general protection fault in jbd2_journal_dirty_metadata (2)

[syzbot] [ocfs2?] [ext4?] general protection fault in jbd2_journal_dirty_metadata (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    08d0d3466664 Merge tag 'net-7.1-rc2' of git://git.kernel.o..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=152f81ce580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=4caf64b1ee83dac0
dashboard link: https://syzkaller.appspot.com/bug?extid=98f651460e558a21baae
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1415f2d2580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=132f81ce580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c5abd4fcc5ba/disk-08d0d346.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/896c46fd9ce9/vmlinux-08d0d346.xz
kernel image: https://storage.googleapis.com/syzbot-assets/04a44a684bb3/bzImage-08d0d346.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/b6c8c7ca94d0/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=14e8a082580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+98f651460e558a21baae@syzkaller.appspotmail.com

(syz.2.23,6028,0):__ocfs2_remove_xattr_range:786 ERROR: status = -30
(syz.2.23,6028,0):ocfs2_xattr_shrink_size:840 ERROR: status = -30
(syz.2.23,6028,0):__ocfs2_journal_access:724 ERROR: Error -30 getting 1 access to buffer!
(syz.2.23,6028,0):ocfs2_xa_prepare_entry:2182 ERROR: status = -30
(syz.2.23,6028,0):ocfs2_xa_set:2285 ERROR: status = -30
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 6028 Comm: syz.2.23 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
RIP: 0010:jbd2_journal_dirty_metadata+0x4a/0xd30 fs/jbd2/transaction.c:1520
Code: 00 fc ff df e8 07 27 29 ff 4c 89 fd 48 c1 ed 03 42 80 7c 35 00 00 74 08 4c 89 ff e8 f0 61 94 ff 49 8b 1f 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df e8 d7 61 94 ff 48 89 1c 24 4c 8b 2b
RSP: 0018:ffffc90003766bc0 EFLAGS: 00010256
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888035c3dc40
RDX: 0000000000000000 RSI: ffff88805927b9f8 RDI: ffff888034ddbf20
RBP: 1ffff110069bb7e4 R08: ffffffff9030a1f7 R09: 1ffffffff206143e
R10: dffffc0000000000 R11: fffffbfff206143f R12: dffffc0000000000
R13: 1ffff920006ecd94 R14: dffffc0000000000 R15: ffff888034ddbf20
FS:  000055556c64d500(0000) GS:ffff888125290000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8ff9c72700 CR3: 000000007908f000 CR4: 0000000000350ef0
Call Trace:
 <TASK>
 ocfs2_journal_dirty+0x130/0x700 fs/ocfs2/journal.c:831
 ocfs2_xa_journal_dirty fs/ocfs2/xattr.c:1483 [inline]
 ocfs2_xa_set+0x15e3/0x2ec0 fs/ocfs2/xattr.c:2294
 ocfs2_xattr_block_set+0x3e0/0x33c0 fs/ocfs2/xattr.c:3016
 __ocfs2_xattr_set_handle+0x6b3/0xf50 fs/ocfs2/xattr.c:3418
 ocfs2_xattr_set+0xf3f/0x13e0 fs/ocfs2/xattr.c:3681
 __vfs_setxattr+0x43c/0x480 fs/xattr.c:218
 __vfs_setxattr_noperm+0x12d/0x660 fs/xattr.c:252
 vfs_setxattr+0x163/0x360 fs/xattr.c:339
 do_setxattr fs/xattr.c:654 [inline]
 filename_setxattr+0x296/0x630 fs/xattr.c:682
 path_setxattrat+0x3eb/0x440 fs/xattr.c:726
 __do_sys_setxattr fs/xattr.c:760 [inline]
 __se_sys_setxattr fs/xattr.c:756 [inline]
 __x64_sys_setxattr+0xbc/0xe0 fs/xattr.c:756
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8ff9d9cdd9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd9c92e118 EFLAGS: 00000246 ORIG_RAX: 00000000000000bc
RAX: ffffffffffffffda RBX: 00007f8ffa015fa0 RCX: 00007f8ff9d9cdd9
RDX: 0000000000000000 RSI: 0000200000000140 RDI: 0000200000000080
RBP: 00007f8ff9e32d69 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f8ffa015fac R14: 00007f8ffa015fa0 R15: 00007f8ffa015fa0
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:jbd2_journal_dirty_metadata+0x4a/0xd30 fs/jbd2/transaction.c:1520
Code: 00 fc ff df e8 07 27 29 ff 4c 89 fd 48 c1 ed 03 42 80 7c 35 00 00 74 08 4c 89 ff e8 f0 61 94 ff 49 8b 1f 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df e8 d7 61 94 ff 48 89 1c 24 4c 8b 2b
RSP: 0018:ffffc90003766bc0 EFLAGS: 00010256
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888035c3dc40
RDX: 0000000000000000 RSI: ffff88805927b9f8 RDI: ffff888034ddbf20
RBP: 1ffff110069bb7e4 R08: ffffffff9030a1f7 R09: 1ffffffff206143e
R10: dffffc0000000000 R11: fffffbfff206143f R12: dffffc0000000000
R13: 1ffff920006ecd94 R14: dffffc0000000000 R15: ffff888034ddbf20
FS:  000055556c64d500(0000) GS:ffff888125290000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000557909eb6950 CR3: 000000007908f000 CR4: 0000000000350ef0
----------------
Code disassembly (best guess), 4 bytes skipped:
   0:	e8 07 27 29 ff       	call   0xff29270c
   5:	4c 89 fd             	mov    %r15,%rbp
   8:	48 c1 ed 03          	shr    $0x3,%rbp
   c:	42 80 7c 35 00 00    	cmpb   $0x0,0x0(%rbp,%r14,1)
  12:	74 08                	je     0x1c
  14:	4c 89 ff             	mov    %r15,%rdi
  17:	e8 f0 61 94 ff       	call   0xff94620c
  1c:	49 8b 1f             	mov    (%r15),%rbx
  1f:	48 89 d8             	mov    %rbx,%rax
  22:	48 c1 e8 03          	shr    $0x3,%rax
* 26:	42 80 3c 30 00       	cmpb   $0x0,(%rax,%r14,1) <-- trapping instruction
  2b:	74 08                	je     0x35
  2d:	48 89 df             	mov    %rbx,%rdi
  30:	e8 d7 61 94 ff       	call   0xff94620c
  35:	48 89 1c 24          	mov    %rbx,(%rsp)
  39:	4c 8b 2b             	mov    (%rbx),%r13


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Forwarded: [PATCH] jbd2: check for aborted handle in jbd2_journal_dirty_metadata()

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] jbd2: check for aborted handle in jbd2_journal_dirty_metadata()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


jbd2_journal_dirty_metadata() unconditionally dereferences
handle->h_transaction at function entry to obtain the journal pointer:

	transaction_t *transaction = handle->h_transaction;
	journal_t *journal = transaction->t_journal;

However, h_transaction may legitimately be NULL for an aborted handle.
The is_handle_aborted() helper in include/linux/jbd2.h explicitly
treats !h_transaction as one of the aborted states:

	if (handle->h_aborted || !handle->h_transaction)
		return 1;

Every other entry point in fs/jbd2/transaction.c
(jbd2_journal_get_{write,undo,create}_access, jbd2_journal_extend,
jbd2_journal_restart, jbd2_journal_stop, etc.) guards against this
with an is_handle_aborted() check before any dereference of
h_transaction. jbd2_journal_dirty_metadata() was missing this guard.

This is reachable from ocfs2's xattr code. ocfs2_xa_set() intentionally
falls through to ocfs2_xa_journal_dirty() even after
ocfs2_xa_prepare_entry() fails, on the assumption that the buffer
needs to be journaled to record any partial modifications (see the
comment above the out_dirty label in fs/ocfs2/xattr.c). If the failure
was caused by the journal being aborted -- e.g. an underlying I/O
error during a sub-operation such as __ocfs2_remove_xattr_range() --
the handle's h_transaction has been cleared by the abort path, and
the unconditional deref in jbd2_journal_dirty_metadata() becomes a
NULL deref.

Reproduced by syzbot with a crafted ocfs2 image where I/O against the
loop device backing the mount is sabotaged via LOOP_SET_STATUS64
between two setxattr() calls, causing the second setxattr (which
truncates an external xattr value) to abort the journal mid-flight:

  Oops: general protection fault, probably for non-canonical
        address 0xdffffc0000000000
  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  RIP: jbd2_journal_dirty_metadata+0x4a/0xd30 fs/jbd2/transaction.c:1520
  Call Trace:
   ocfs2_journal_dirty+0x130/0x700 fs/ocfs2/journal.c:831
   ocfs2_xa_journal_dirty fs/ocfs2/xattr.c:1483 [inline]
   ocfs2_xa_set+0x15e3/0x2ec0 fs/ocfs2/xattr.c:2294
   ocfs2_xattr_block_set+0x3e0/0x33c0 fs/ocfs2/xattr.c:3016
   __ocfs2_xattr_set_handle+0x6b3/0xf50 fs/ocfs2/xattr.c:3418
   ocfs2_xattr_set+0xf3f/0x13e0 fs/ocfs2/xattr.c:3681
   __vfs_setxattr+0x43c/0x480 fs/xattr.c:218
   ...

Fix by adding the standard is_handle_aborted() guard at the top of
jbd2_journal_dirty_metadata() and returning -EROFS, matching the
pattern used by every other entry point in this file.
ocfs2_journal_dirty() already handles a non-zero return from
jbd2_journal_dirty_metadata() correctly.

Reported-by: syzbot+98f651460e558a21baae@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=98f651460e558a21baae
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/jbd2/transaction.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index 4885903bbd10..aa0be9e9c876 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1516,14 +1516,19 @@ void jbd2_buffer_abort_trigger(struct journal_head *jh,
  */
 int jbd2_journal_dirty_metadata(handle_t *handle, struct buffer_head *bh)
 {
-	transaction_t *transaction = handle->h_transaction;
-	journal_t *journal = transaction->t_journal;
+	transaction_t *transaction;
+	journal_t *journal;
 	struct journal_head *jh;
 	int ret = 0;
 
+	if (is_handle_aborted(handle))
+		return -EROFS;
 	if (!buffer_jbd(bh))
 		return -EUCLEAN;
 
+	transaction = handle->h_transaction;
+	journal = transaction->t_journal;
+
 	/*
 	 * We don't grab jh reference here since the buffer must be part
 	 * of the running transaction.
-- 
2.43.0

Re: [syzbot] [ocfs2?] [ext4?] general protection fault in jbd2_journal_dirty_metadata (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+98f651460e558a21baae@syzkaller.appspotmail.com
Tested-by: syzbot+98f651460e558a21baae@syzkaller.appspotmail.com

Tested on:

commit:         a293ec25 Merge tag 'linux_kselftest-fixes-7.1-rc3' of ..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15684ad2580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=4caf64b1ee83dac0
dashboard link: https://syzkaller.appspot.com/bug?extid=98f651460e558a21baae
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=15a13a36580000

Note: testing is done by a robot and is best-effort only.