Skip to contentSkip to conversation

WARNING in ovl_encode_real_fh

syzbot New syzbot 3 participants 12 messages Oct 28, 2024 – Dec 19, 2024

Subsystems (2)
VFS Overlay filesystem
lore
Share & tools
lore

syzbot

author syzbot
#0 lore raw

Hello,

syzbot found the following issue on:

HEAD commit:    c2ee9f594da8 KVM: selftests: Fix build on on non-x86 archi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=178bf640580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=fc6f8ce8c5369043
dashboard link: https://syzkaller.appspot.com/bug?extid=ec07f6f5ce62b858579f
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=112628a7980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=104bf640580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-c2ee9f59.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/8a3541902b13/vmlinux-c2ee9f59.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a00efacc2604/bzImage-c2ee9f59.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:

Reported-by [email protected]

RDX: 0000000000000000 RSI: 0000000020000440 RDI: 00000000ffffff9c
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000003932
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffc9b4e42fc
R13: 0000000000000004 R14: 431bde82d7b634db R15: 00007ffc9b4e4330

 </TASK>
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5103 at fs/overlayfs/copy_up.c:448 ovl_encode_real_fh+0x2e2/0x410 fs/overlayfs/copy_up.c:448
Modules linked in:
CPU: 0 UID: 0 PID: 5103 Comm: syz-executor195 Not tainted 6.12.0-rc4-syzkaller-00047-gc2ee9f594da8 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:ovl_encode_real_fh+0x2e2/0x410 fs/overlayfs/copy_up.c:448
Code: 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 05 b6 75 fe 90 0f 0b 90 eb 14 e8 fa b5 75 fe 90 0f 0b 90 eb 09 e8 ef b5 75 fe 90 <0f> 0b 90 4c 89 ff e8 b3 6a d3 fe 49 c7 c7 fb ff ff ff eb 8b 89 d1
RSP: 0018:ffffc9000b1f73c0 EFLAGS: 00010293
RAX: ffffffff831f21f1 RBX: 1ffff9200163ee80 RCX: ffff88801fbc2440
RDX: 0000000000000000 RSI: 00000000000000ff RDI: 00000000000000ff
RBP: ffffc9000b1f7470 R08: ffffffff831f208c R09: 1ffffffff2039fdd
R10: dffffc0000000000 R11: fffffbfff2039fde R12: 00000000000000ff
R13: 0000000000000080 R14: 1ffff9200163ee7c R15: ffff888036790300
FS:  0000555590223480(0000) GS:ffff88801fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6fdf3d7709 CR3: 0000000040e6e000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 ovl_get_origin_fh fs/overlayfs/copy_up.c:484 [inline]
 ovl_do_copy_up fs/overlayfs/copy_up.c:961 [inline]
 ovl_copy_up_one fs/overlayfs/copy_up.c:1203 [inline]
 ovl_copy_up_flags+0x1068/0x46f0 fs/overlayfs/copy_up.c:1258
 ovl_setattr+0x11d/0x5a0 fs/overlayfs/inode.c:40
 notify_change+0xbca/0xe90 fs/attr.c:503
 chown_common+0x501/0x850 fs/open.c:793
 do_fchownat+0x16a/0x240 fs/open.c:824
 __do_sys_fchownat fs/open.c:839 [inline]
 __se_sys_fchownat fs/open.c:836 [inline]
 __x64_sys_fchownat+0xb5/0xd0 fs/open.c:836
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f6fdf3812f9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 31 1b 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc9b4e42a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000104
RAX: ffffffffffffffda RBX: 00007ffc9b4e42b0 RCX: 00007f6fdf3812f9
RDX: 0000000000000000 RSI: 0000000020000440 RDI: 00000000ffffff9c
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000003932
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffc9b4e42fc
R13: 0000000000000004 R14: 431bde82d7b634db R15: 00007ffc9b4e4330
 </TASK>

---
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 [email protected].

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

#1 lore raw

When the memory is insufficient, the allocation of fh fails, which causes the failure to obtain the dentry fid, and finally causes the dentry encoding to fail.
Retry is used to avoid the failure of fh allocation caused by temporary insufficient memory.

#syz test

fs/overlayfs/copy_up.c +9 -2
index 2ed6ad641a20..1e027a3cf084 100644
@@ -423,15 +423,22 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
 	int fh_type, dwords;
 	int buflen = MAX_HANDLE_SZ;
 	uuid_t *uuid = &real->d_sb->s_uuid;
-	int err;
+	int err, rtt = 0;
 
 	/* Make sure the real fid stays 32bit aligned */
 	BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);
 	BUILD_BUG_ON(MAX_HANDLE_SZ + OVL_FH_FID_OFFSET > 255);
 
+retry:
 	fh = kzalloc(buflen + OVL_FH_FID_OFFSET, GFP_KERNEL);
-	if (!fh)
+	if (!fh) {
+		if (!rtt) {
+			cond_resched();
+			rtt++;
+			goto retry;
+		}
 		return ERR_PTR(-ENOMEM);
+	}
 
 	/*
 	 * We encode a non-connectable file handle for non-dir, because we
author syzbot Tested-by
#2 lore raw
syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Hello,

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

Reported-by [email protected]
Tested-by [email protected]

Tested on:

commit:         c1e939a2 Merge tag 'cgroup-for-6.12-rc5-fixes' of git:..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=123ee2a7980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=35698c25466f388c
dashboard link: https://syzkaller.appspot.com/bug?extid=ec07f6f5ce62b858579f
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=123c8630580000

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

maintainer
#3 lore raw
In reply to Edward Adam Davis
Quoted 29 lines · Edward Adam Davis

When the memory is insufficient, the allocation of fh fails, which causes the failure to obtain the dentry fid, and finally causes the dentry encoding to fail.
Retry is used to avoid the failure of fh allocation caused by temporary insufficient memory.

#syz test

fs/overlayfs/copy_up.c +3 -2
index 2ed6ad641a20..1e027a3cf084 100644
@@ -423,15 +423,22 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
        int fh_type, dwords;
        int buflen = MAX_HANDLE_SZ;
        uuid_t *uuid = &real->d_sb->s_uuid;
-       int err;
+       int err, rtt = 0;
 
        /* Make sure the real fid stays 32bit aligned */
        BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);
        BUILD_BUG_ON(MAX_HANDLE_SZ + OVL_FH_FID_OFFSET > 255);
 
+retry:
        fh = kzalloc(buflen + OVL_FH_FID_OFFSET, GFP_KERNEL);
-       if (!fh)
+       if (!fh) {

fs/overlayfs/copy_up.c struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real, · line 444

Quoted 10 lines
fs/overlayfs/copy_up.c +6 -0
+               if (!rtt) {
+                       cond_resched();
+                       rtt++;
+                       goto retry;
+               }
                return ERR_PTR(-ENOMEM);
+       }
 
        /*
         * We encode a non-connectable file handle for non-dir, because we

This endless loop is out of the question and anyway, syzbot reported a WARN_ON in line 448:

            WARN_ON(fh_type == FILEID_INVALID))

How does that have to do with memory allocation failure? What am I missing?

Probably this WARN_ON as well as the one in line 446 should be relaxed because it is perfectly possible for fs to return negative or FILEID_INVALID for encoding a file handle even if fs supports encoding file handles.

Thanks,
Amir.

#4 lore raw
Quoted 41 lines · Amir Goldstein
Quoted 28 lines

When the memory is insufficient, the allocation of fh fails, which causes the failure to obtain the dentry fid, and finally causes the dentry encoding to fail.
Retry is used to avoid the failure of fh allocation caused by temporary insufficient memory.

#syz test

fs/overlayfs/copy_up.c +3 -2
index 2ed6ad641a20..1e027a3cf084 100644
@@ -423,15 +423,22 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
        int fh_type, dwords;
        int buflen = MAX_HANDLE_SZ;
        uuid_t *uuid = &real->d_sb->s_uuid;
-       int err;
+       int err, rtt = 0;
 
        /* Make sure the real fid stays 32bit aligned */
        BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);
        BUILD_BUG_ON(MAX_HANDLE_SZ + OVL_FH_FID_OFFSET > 255);
 
+retry:
        fh = kzalloc(buflen + OVL_FH_FID_OFFSET, GFP_KERNEL);
-       if (!fh)
+       if (!fh) {

fs/overlayfs/copy_up.c struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real, · line 444

Quoted 10 lines
fs/overlayfs/copy_up.c +6 -0
+               if (!rtt) {
+                       cond_resched();
+                       rtt++;
+                       goto retry;
+               }
                return ERR_PTR(-ENOMEM);
+       }
 
        /*
         * We encode a non-connectable file handle for non-dir, because we

This endless loop is out of the question and anyway, syzbot reported a WARN_ON in line 448:

Quoted 4 lines
            WARN_ON(fh_type == FILEID_INVALID))

How does that have to do with memory allocation failure? What am I missing?

Look following log, it in https://syzkaller.appspot.com/text?tag=CrashLog&x=178bf640580000:

[   64.050342][ T5103] FAULT_INJECTION: forcing a failure.
[   64.050342][ T5103] name failslab, interval 1, probability 0, space 0, times 0
[   64.055933][ T5103] CPU: 0 UID: 0 PID: 5103 Comm: syz-executor195 Not tainted 6.12.0-rc4-syzkaller-00047-gc2ee9f594da8 #0
[   64.060023][ T5103] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
[   64.063941][ T5103] Call Trace:
[   64.065199][ T5103]  <TASK>
[   64.066296][ T5103]  dump_stack_lvl+0x241/0x360
[   64.068028][ T5103]  ? __pfx_dump_stack_lvl+0x10/0x10
[   64.069939][ T5103]  ? __pfx__printk+0x10/0x10
[   64.071667][ T5103]  ? __kmalloc_cache_noprof+0x44/0x2c0
[   64.073756][ T5103]  ? __pfx___might_resched+0x10/0x10
[   64.075720][ T5103]  should_fail_ex+0x3b0/0x4e0
[   64.077525][ T5103]  should_failslab+0xac/0x100
[   64.079341][ T5103]  ? ovl_encode_real_fh+0xdf/0x410
[   64.081295][ T5103]  __kmalloc_cache_noprof+0x6c/0x2c0
[   64.083282][ T5103]  ? dput+0x37/0x2b0
[   64.084758][ T5103]  ovl_encode_real_fh+0xdf/0x410
[   64.086578][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
[   64.088687][ T5103]  ? _raw_spin_unlock+0x28/0x50
[   64.090550][ T5103]  ovl_encode_fh+0x388/0xc20
[   64.092281][ T5103]  exportfs_encode_fh+0x1bd/0x3e0
[   64.094122][ T5103]  ovl_encode_real_fh+0x129/0x410
[   64.095883][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
[   64.097852][ T5103]  ? bpf_lsm_capable+0x9/0x10
[   64.099620][ T5103]  ? capable+0x89/0xe0
[   64.101064][ T5103]  ovl_copy_up_flags+0x1068/0x46f0
Quoted 6 lines

Probably this WARN_ON as well as the one in line 446 should be relaxed because it is perfectly possible for fs to return negative or FILEID_INVALID for encoding a file handle even if fs supports encoding file handles.

BR,
Edward

maintainer
#5 lore raw
Quoted 66 lines · Edward Adam Davis
Quoted 41 lines · Amir Goldstein
Quoted 28 lines

When the memory is insufficient, the allocation of fh fails, which causes the failure to obtain the dentry fid, and finally causes the dentry encoding to fail.
Retry is used to avoid the failure of fh allocation caused by temporary insufficient memory.

#syz test

fs/overlayfs/copy_up.c +3 -2
index 2ed6ad641a20..1e027a3cf084 100644
@@ -423,15 +423,22 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
        int fh_type, dwords;
        int buflen = MAX_HANDLE_SZ;
        uuid_t *uuid = &real->d_sb->s_uuid;
-       int err;
+       int err, rtt = 0;
 
        /* Make sure the real fid stays 32bit aligned */
        BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);
        BUILD_BUG_ON(MAX_HANDLE_SZ + OVL_FH_FID_OFFSET > 255);
 
+retry:
        fh = kzalloc(buflen + OVL_FH_FID_OFFSET, GFP_KERNEL);
-       if (!fh)
+       if (!fh) {

fs/overlayfs/copy_up.c struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real, · line 444

Quoted 10 lines
fs/overlayfs/copy_up.c +6 -0
+               if (!rtt) {
+                       cond_resched();
+                       rtt++;
+                       goto retry;
+               }
                return ERR_PTR(-ENOMEM);
+       }
 
        /*
         * We encode a non-connectable file handle for non-dir, because we

This endless loop is out of the question and anyway, syzbot reported a WARN_ON in line 448:

Quoted 4 lines
            WARN_ON(fh_type == FILEID_INVALID))

How does that have to do with memory allocation failure? What am I missing?

Look following log, it in https://syzkaller.appspot.com/text?tag=CrashLog&x=178bf640580000:

[   64.050342][ T5103] FAULT_INJECTION: forcing a failure.
[   64.050342][ T5103] name failslab, interval 1, probability 0, space 0, times 0
[   64.055933][ T5103] CPU: 0 UID: 0 PID: 5103 Comm: syz-executor195 Not tainted 6.12.0-rc4-syzkaller-00047-gc2ee9f594da8 #0
[   64.060023][ T5103] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
[   64.063941][ T5103] Call Trace:
[   64.065199][ T5103]  <TASK>
[   64.066296][ T5103]  dump_stack_lvl+0x241/0x360
[   64.068028][ T5103]  ? __pfx_dump_stack_lvl+0x10/0x10
[   64.069939][ T5103]  ? __pfx__printk+0x10/0x10
[   64.071667][ T5103]  ? __kmalloc_cache_noprof+0x44/0x2c0
[   64.073756][ T5103]  ? __pfx___might_resched+0x10/0x10
[   64.075720][ T5103]  should_fail_ex+0x3b0/0x4e0
[   64.077525][ T5103]  should_failslab+0xac/0x100
[   64.079341][ T5103]  ? ovl_encode_real_fh+0xdf/0x410
[   64.081295][ T5103]  __kmalloc_cache_noprof+0x6c/0x2c0
[   64.083282][ T5103]  ? dput+0x37/0x2b0
[   64.084758][ T5103]  ovl_encode_real_fh+0xdf/0x410
[   64.086578][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
Quoted 8 lines
[   64.088687][ T5103]  ? _raw_spin_unlock+0x28/0x50
[   64.090550][ T5103]  ovl_encode_fh+0x388/0xc20
[   64.092281][ T5103]  exportfs_encode_fh+0x1bd/0x3e0
[   64.094122][ T5103]  ovl_encode_real_fh+0x129/0x410
[   64.095883][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
[   64.097852][ T5103]  ? bpf_lsm_capable+0x9/0x10
[   64.099620][ T5103]  ? capable+0x89/0xe0
[   64.101064][ T5103]  ovl_copy_up_flags+0x1068/0x46f0

I see. it is nested overlayfs, so a memory allocation failure in the lower overlayfs, causes ovl_encode_fh() to return FILEID_INVALID.

Quoted 6 lines
Quoted 6 lines

Probably this WARN_ON as well as the one in line 446 should be relaxed because it is perfectly possible for fs to return negative or FILEID_INVALID for encoding a file handle even if fs supports encoding file handles.

As I wrote, the correct fix is to relax the WARN_ON from fh_type == FILEID_INVALID and fh_type < 0 conditions because those are valid return values from filesystems.

Thanks,
Amir,

#6 lore raw
Quoted 86 lines · Amir Goldstein
Quoted 66 lines · Edward Adam Davis
Quoted 41 lines · Amir Goldstein
Quoted 28 lines

When the memory is insufficient, the allocation of fh fails, which causes the failure to obtain the dentry fid, and finally causes the dentry encoding to fail.
Retry is used to avoid the failure of fh allocation caused by temporary insufficient memory.

#syz test

fs/overlayfs/copy_up.c +3 -2
index 2ed6ad641a20..1e027a3cf084 100644
@@ -423,15 +423,22 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
        int fh_type, dwords;
        int buflen = MAX_HANDLE_SZ;
        uuid_t *uuid = &real->d_sb->s_uuid;
-       int err;
+       int err, rtt = 0;
 
        /* Make sure the real fid stays 32bit aligned */
        BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);
        BUILD_BUG_ON(MAX_HANDLE_SZ + OVL_FH_FID_OFFSET > 255);
 
+retry:
        fh = kzalloc(buflen + OVL_FH_FID_OFFSET, GFP_KERNEL);
-       if (!fh)
+       if (!fh) {

fs/overlayfs/copy_up.c struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real, · line 444

Quoted 10 lines
fs/overlayfs/copy_up.c +6 -0
+               if (!rtt) {
+                       cond_resched();
+                       rtt++;
+                       goto retry;
+               }
                return ERR_PTR(-ENOMEM);
+       }
 
        /*
         * We encode a non-connectable file handle for non-dir, because we

This endless loop is out of the question and anyway, syzbot reported a WARN_ON in line 448:

Quoted 4 lines
            WARN_ON(fh_type == FILEID_INVALID))

How does that have to do with memory allocation failure? What am I missing?

Look following log, it in https://syzkaller.appspot.com/text?tag=CrashLog&x=178bf640580000:

[   64.050342][ T5103] FAULT_INJECTION: forcing a failure.
[   64.050342][ T5103] name failslab, interval 1, probability 0, space 0, times 0
[   64.055933][ T5103] CPU: 0 UID: 0 PID: 5103 Comm: syz-executor195 Not tainted 6.12.0-rc4-syzkaller-00047-gc2ee9f594da8 #0
[   64.060023][ T5103] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
[   64.063941][ T5103] Call Trace:
[   64.065199][ T5103]  <TASK>
[   64.066296][ T5103]  dump_stack_lvl+0x241/0x360
[   64.068028][ T5103]  ? __pfx_dump_stack_lvl+0x10/0x10
[   64.069939][ T5103]  ? __pfx__printk+0x10/0x10
[   64.071667][ T5103]  ? __kmalloc_cache_noprof+0x44/0x2c0
[   64.073756][ T5103]  ? __pfx___might_resched+0x10/0x10
[   64.075720][ T5103]  should_fail_ex+0x3b0/0x4e0
[   64.077525][ T5103]  should_failslab+0xac/0x100
[   64.079341][ T5103]  ? ovl_encode_real_fh+0xdf/0x410
[   64.081295][ T5103]  __kmalloc_cache_noprof+0x6c/0x2c0
[   64.083282][ T5103]  ? dput+0x37/0x2b0
[   64.084758][ T5103]  ovl_encode_real_fh+0xdf/0x410
[   64.086578][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
Quoted 8 lines
[   64.088687][ T5103]  ? _raw_spin_unlock+0x28/0x50
[   64.090550][ T5103]  ovl_encode_fh+0x388/0xc20
[   64.092281][ T5103]  exportfs_encode_fh+0x1bd/0x3e0
[   64.094122][ T5103]  ovl_encode_real_fh+0x129/0x410
[   64.095883][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
[   64.097852][ T5103]  ? bpf_lsm_capable+0x9/0x10
[   64.099620][ T5103]  ? capable+0x89/0xe0
[   64.101064][ T5103]  ovl_copy_up_flags+0x1068/0x46f0

I see. it is nested overlayfs, so a memory allocation failure in the lower overlayfs, causes ovl_encode_fh() to return FILEID_INVALID.

Quoted 6 lines
Quoted 6 lines

Probably this WARN_ON as well as the one in line 446 should be relaxed because it is perfectly possible for fs to return negative or FILEID_INVALID for encoding a file handle even if fs supports encoding file handles.

Quoted 3 lines

As I wrote, the correct fix is to relax the WARN_ON from fh_type == FILEID_INVALID and fh_type < 0 conditions because those are valid return values from filesystems.

Oh, You mean is following diff?

fs/overlayfs/copy_up.c +1 -3
index 2ed6ad641a20..32890cc0dd4a 100644
@@ -443,9 +443,7 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
 	buflen = (dwords << 2);
 
 	err = -EIO;
-	if (WARN_ON(fh_type < 0) ||
-	    WARN_ON(buflen > MAX_HANDLE_SZ) ||
-	    WARN_ON(fh_type == FILEID_INVALID))
+	if (WARN_ON(buflen > MAX_HANDLE_SZ))
 		goto out_err;
 
 	fh->fb.version = OVL_FH_VERSION;

BR,
Edward

maintainer
#7 lore raw
Quoted 98 lines · Edward Adam Davis
Quoted 86 lines · Amir Goldstein
Quoted 66 lines · Edward Adam Davis
Quoted 41 lines · Amir Goldstein
Quoted 28 lines

When the memory is insufficient, the allocation of fh fails, which causes the failure to obtain the dentry fid, and finally causes the dentry encoding to fail.
Retry is used to avoid the failure of fh allocation caused by temporary insufficient memory.

#syz test

fs/overlayfs/copy_up.c +3 -2
index 2ed6ad641a20..1e027a3cf084 100644
@@ -423,15 +423,22 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
        int fh_type, dwords;
        int buflen = MAX_HANDLE_SZ;
        uuid_t *uuid = &real->d_sb->s_uuid;
-       int err;
+       int err, rtt = 0;
 
        /* Make sure the real fid stays 32bit aligned */
        BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);
        BUILD_BUG_ON(MAX_HANDLE_SZ + OVL_FH_FID_OFFSET > 255);
 
+retry:
        fh = kzalloc(buflen + OVL_FH_FID_OFFSET, GFP_KERNEL);
-       if (!fh)
+       if (!fh) {

fs/overlayfs/copy_up.c struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real, · line 444

Quoted 10 lines
fs/overlayfs/copy_up.c +6 -0
+               if (!rtt) {
+                       cond_resched();
+                       rtt++;
+                       goto retry;
+               }
                return ERR_PTR(-ENOMEM);
+       }
 
        /*
         * We encode a non-connectable file handle for non-dir, because we

This endless loop is out of the question and anyway, syzbot reported a WARN_ON in line 448:

Quoted 4 lines
            WARN_ON(fh_type == FILEID_INVALID))

How does that have to do with memory allocation failure? What am I missing?

Look following log, it in https://syzkaller.appspot.com/text?tag=CrashLog&x=178bf640580000:

[   64.050342][ T5103] FAULT_INJECTION: forcing a failure.
[   64.050342][ T5103] name failslab, interval 1, probability 0, space 0, times 0
[   64.055933][ T5103] CPU: 0 UID: 0 PID: 5103 Comm: syz-executor195 Not tainted 6.12.0-rc4-syzkaller-00047-gc2ee9f594da8 #0
[   64.060023][ T5103] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
[   64.063941][ T5103] Call Trace:
[   64.065199][ T5103]  <TASK>
[   64.066296][ T5103]  dump_stack_lvl+0x241/0x360
[   64.068028][ T5103]  ? __pfx_dump_stack_lvl+0x10/0x10
[   64.069939][ T5103]  ? __pfx__printk+0x10/0x10
[   64.071667][ T5103]  ? __kmalloc_cache_noprof+0x44/0x2c0
[   64.073756][ T5103]  ? __pfx___might_resched+0x10/0x10
[   64.075720][ T5103]  should_fail_ex+0x3b0/0x4e0
[   64.077525][ T5103]  should_failslab+0xac/0x100
[   64.079341][ T5103]  ? ovl_encode_real_fh+0xdf/0x410
[   64.081295][ T5103]  __kmalloc_cache_noprof+0x6c/0x2c0
[   64.083282][ T5103]  ? dput+0x37/0x2b0
[   64.084758][ T5103]  ovl_encode_real_fh+0xdf/0x410
[   64.086578][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
Quoted 8 lines
[   64.088687][ T5103]  ? _raw_spin_unlock+0x28/0x50
[   64.090550][ T5103]  ovl_encode_fh+0x388/0xc20
[   64.092281][ T5103]  exportfs_encode_fh+0x1bd/0x3e0
[   64.094122][ T5103]  ovl_encode_real_fh+0x129/0x410
[   64.095883][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
[   64.097852][ T5103]  ? bpf_lsm_capable+0x9/0x10
[   64.099620][ T5103]  ? capable+0x89/0xe0
[   64.101064][ T5103]  ovl_copy_up_flags+0x1068/0x46f0

I see. it is nested overlayfs, so a memory allocation failure in the lower overlayfs, causes ovl_encode_fh() to return FILEID_INVALID.

Quoted 6 lines
Quoted 6 lines

Probably this WARN_ON as well as the one in line 446 should be relaxed because it is perfectly possible for fs to return negative or FILEID_INVALID for encoding a file handle even if fs supports encoding file handles.

Quoted 3 lines

As I wrote, the correct fix is to relax the WARN_ON from fh_type == FILEID_INVALID and fh_type < 0 conditions because those are valid return values from filesystems.

Oh, You mean is following diff?

fs/overlayfs/copy_up.c +0 -0
index 2ed6ad641a20..32890cc0dd4a 100644

fs/overlayfs/copy_up.c struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real, · line 448

Quoted 9 lines
fs/overlayfs/copy_up.c +1 -3
@@ -443,9 +443,7 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
        buflen = (dwords << 2);
 
        err = -EIO;
-       if (WARN_ON(fh_type < 0) ||
-           WARN_ON(buflen > MAX_HANDLE_SZ) ||
-           WARN_ON(fh_type == FILEID_INVALID))
+       if (WARN_ON(buflen > MAX_HANDLE_SZ))
                goto out_err;

No. sorry, what I meant with "relax WARN_ON" was to remove the WARN_ON, so:

       err = -EIO;
       if (fh_type < 0 || fh_type == FILEID_INVALID ||
           WARN_ON(buflen > MAX_HANDLE_SZ))
                 goto out_err;

Meaning that error should definitely be returned in those cases, but there is no reason for the assertion which is what syzbot was complaining about.

Thanks,
Amir.

#8 lore raw
Quoted 111 lines · Amir Goldstein
Quoted 98 lines · Edward Adam Davis
Quoted 86 lines · Amir Goldstein
Quoted 66 lines · Edward Adam Davis
Quoted 41 lines · Amir Goldstein
Quoted 28 lines

When the memory is insufficient, the allocation of fh fails, which causes the failure to obtain the dentry fid, and finally causes the dentry encoding to fail.
Retry is used to avoid the failure of fh allocation caused by temporary insufficient memory.

#syz test

fs/overlayfs/copy_up.c +3 -2
index 2ed6ad641a20..1e027a3cf084 100644
@@ -423,15 +423,22 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
        int fh_type, dwords;
        int buflen = MAX_HANDLE_SZ;
        uuid_t *uuid = &real->d_sb->s_uuid;
-       int err;
+       int err, rtt = 0;
 
        /* Make sure the real fid stays 32bit aligned */
        BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);
        BUILD_BUG_ON(MAX_HANDLE_SZ + OVL_FH_FID_OFFSET > 255);
 
+retry:
        fh = kzalloc(buflen + OVL_FH_FID_OFFSET, GFP_KERNEL);
-       if (!fh)
+       if (!fh) {

fs/overlayfs/copy_up.c struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real, · line 444

Quoted 10 lines
fs/overlayfs/copy_up.c +6 -0
+               if (!rtt) {
+                       cond_resched();
+                       rtt++;
+                       goto retry;
+               }
                return ERR_PTR(-ENOMEM);
+       }
 
        /*
         * We encode a non-connectable file handle for non-dir, because we

This endless loop is out of the question and anyway, syzbot reported a WARN_ON in line 448:

Quoted 4 lines
            WARN_ON(fh_type == FILEID_INVALID))

How does that have to do with memory allocation failure? What am I missing?

Look following log, it in https://syzkaller.appspot.com/text?tag=CrashLog&x=178bf640580000:

[   64.050342][ T5103] FAULT_INJECTION: forcing a failure.
[   64.050342][ T5103] name failslab, interval 1, probability 0, space 0, times 0
[   64.055933][ T5103] CPU: 0 UID: 0 PID: 5103 Comm: syz-executor195 Not tainted 6.12.0-rc4-syzkaller-00047-gc2ee9f594da8 #0
[   64.060023][ T5103] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
[   64.063941][ T5103] Call Trace:
[   64.065199][ T5103]  <TASK>
[   64.066296][ T5103]  dump_stack_lvl+0x241/0x360
[   64.068028][ T5103]  ? __pfx_dump_stack_lvl+0x10/0x10
[   64.069939][ T5103]  ? __pfx__printk+0x10/0x10
[   64.071667][ T5103]  ? __kmalloc_cache_noprof+0x44/0x2c0
[   64.073756][ T5103]  ? __pfx___might_resched+0x10/0x10
[   64.075720][ T5103]  should_fail_ex+0x3b0/0x4e0
[   64.077525][ T5103]  should_failslab+0xac/0x100
[   64.079341][ T5103]  ? ovl_encode_real_fh+0xdf/0x410
[   64.081295][ T5103]  __kmalloc_cache_noprof+0x6c/0x2c0
[   64.083282][ T5103]  ? dput+0x37/0x2b0
[   64.084758][ T5103]  ovl_encode_real_fh+0xdf/0x410
[   64.086578][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
Quoted 8 lines
[   64.088687][ T5103]  ? _raw_spin_unlock+0x28/0x50
[   64.090550][ T5103]  ovl_encode_fh+0x388/0xc20
[   64.092281][ T5103]  exportfs_encode_fh+0x1bd/0x3e0
[   64.094122][ T5103]  ovl_encode_real_fh+0x129/0x410
[   64.095883][ T5103]  ? __pfx_ovl_encode_real_fh+0x10/0x10
[   64.097852][ T5103]  ? bpf_lsm_capable+0x9/0x10
[   64.099620][ T5103]  ? capable+0x89/0xe0
[   64.101064][ T5103]  ovl_copy_up_flags+0x1068/0x46f0

I see. it is nested overlayfs, so a memory allocation failure in the lower overlayfs, causes ovl_encode_fh() to return FILEID_INVALID.

Quoted 6 lines
Quoted 6 lines

Probably this WARN_ON as well as the one in line 446 should be relaxed because it is perfectly possible for fs to return negative or FILEID_INVALID for encoding a file handle even if fs supports encoding file handles.

Quoted 3 lines

As I wrote, the correct fix is to relax the WARN_ON from fh_type == FILEID_INVALID and fh_type < 0 conditions because those are valid return values from filesystems.

Oh, You mean is following diff?

fs/overlayfs/copy_up.c +0 -0
index 2ed6ad641a20..32890cc0dd4a 100644

fs/overlayfs/copy_up.c struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real, · line 448

Quoted 9 lines
fs/overlayfs/copy_up.c +1 -3
@@ -443,9 +443,7 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
        buflen = (dwords << 2);
 
        err = -EIO;
-       if (WARN_ON(fh_type < 0) ||
-           WARN_ON(buflen > MAX_HANDLE_SZ) ||
-           WARN_ON(fh_type == FILEID_INVALID))
+       if (WARN_ON(buflen > MAX_HANDLE_SZ))
                goto out_err;

No. sorry, what I meant with "relax WARN_ON" was to remove the WARN_ON, so:

Quoted 8 lines
       err = -EIO;
       if (fh_type < 0 || fh_type == FILEID_INVALID ||
           WARN_ON(buflen > MAX_HANDLE_SZ))
                 goto out_err;

Meaning that error should definitely be returned in those cases, but there is no reason for the assertion which is what syzbot was complaining about.

Haha, I was a little dizzy, I deleted too much. Yes, I meant it as your diff.

BR,
Edward

#9 lore raw

PATCH 1/1 overlayfs: retry when getting the dentry fid fails due to lack of memory

In reply to syzbot

Syzbot report a WARNING in ovl_encode_real_fh.
When the memory is insufficient, the allocation of fh fails, which causes the failure to obtain the dentry fid, and finally causes the dentry encoding to fail.
Retry is used to avoid the failure of fh allocation caused by temporary insufficient memory.

Reported-and-tested-by [email protected]
Closes https://syzkaller.appspot.com/bug?extid=ec07f6f5ce62b858579f
Signed-off-by Edward Adam Davis <[email protected]>
---
 fs/overlayfs/copy_up.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)
fs/overlayfs/copy_up.c +9 -2
index 2ed6ad641a20..1e027a3cf084 100644
@@ -423,15 +423,22 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
 	int fh_type, dwords;
 	int buflen = MAX_HANDLE_SZ;
 	uuid_t *uuid = &real->d_sb->s_uuid;
-	int err;
+	int err, rtt = 0;
 
 	/* Make sure the real fid stays 32bit aligned */
 	BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);
 	BUILD_BUG_ON(MAX_HANDLE_SZ + OVL_FH_FID_OFFSET > 255);
 
+retry:
 	fh = kzalloc(buflen + OVL_FH_FID_OFFSET, GFP_KERNEL);
-	if (!fh)
+	if (!fh) {
+		if (!rtt) {
+			cond_resched();
+			rtt++;
+			goto retry;
+		}
 		return ERR_PTR(-ENOMEM);
+	}
 
 	/*
 	 * We encode a non-connectable file handle for non-dir, because we
Signature · 1 line
2.43.0
maintainer
#10 lore raw
In reply to syzbot
Quoted 62 lines · syzbot

Hello,

syzbot found the following issue on:

HEAD commit:    c2ee9f594da8 KVM: selftests: Fix build on on non-x86 archi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=178bf640580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=fc6f8ce8c5369043
dashboard link: https://syzkaller.appspot.com/bug?extid=ec07f6f5ce62b858579f
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=112628a7980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=104bf640580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-c2ee9f59.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/8a3541902b13/vmlinux-c2ee9f59.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a00efacc2604/bzImage-c2ee9f59.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:

Reported-by [email protected]

RDX: 0000000000000000 RSI: 0000000020000440 RDI: 00000000ffffff9c
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000003932
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffc9b4e42fc
R13: 0000000000000004 R14: 431bde82d7b634db R15: 00007ffc9b4e4330

 </TASK>
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5103 at fs/overlayfs/copy_up.c:448 ovl_encode_real_fh+0x2e2/0x410 fs/overlayfs/copy_up.c:448
Modules linked in:
CPU: 0 UID: 0 PID: 5103 Comm: syz-executor195 Not tainted 6.12.0-rc4-syzkaller-00047-gc2ee9f594da8 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:ovl_encode_real_fh+0x2e2/0x410 fs/overlayfs/copy_up.c:448
Code: 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 05 b6 75 fe 90 0f 0b 90 eb 14 e8 fa b5 75 fe 90 0f 0b 90 eb 09 e8 ef b5 75 fe 90 <0f> 0b 90 4c 89 ff e8 b3 6a d3 fe 49 c7 c7 fb ff ff ff eb 8b 89 d1
RSP: 0018:ffffc9000b1f73c0 EFLAGS: 00010293
RAX: ffffffff831f21f1 RBX: 1ffff9200163ee80 RCX: ffff88801fbc2440
RDX: 0000000000000000 RSI: 00000000000000ff RDI: 00000000000000ff
RBP: ffffc9000b1f7470 R08: ffffffff831f208c R09: 1ffffffff2039fdd
R10: dffffc0000000000 R11: fffffbfff2039fde R12: 00000000000000ff
R13: 0000000000000080 R14: 1ffff9200163ee7c R15: ffff888036790300
FS:  0000555590223480(0000) GS:ffff88801fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6fdf3d7709 CR3: 0000000040e6e000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 ovl_get_origin_fh fs/overlayfs/copy_up.c:484 [inline]
 ovl_do_copy_up fs/overlayfs/copy_up.c:961 [inline]
 ovl_copy_up_one fs/overlayfs/copy_up.c:1203 [inline]
 ovl_copy_up_flags+0x1068/0x46f0 fs/overlayfs/copy_up.c:1258
 ovl_setattr+0x11d/0x5a0 fs/overlayfs/inode.c:40
 notify_change+0xbca/0xe90 fs/attr.c:503
 chown_common+0x501/0x850 fs/open.c:793
 do_fchownat+0x16a/0x240 fs/open.c:824
 __do_sys_fchownat fs/open.c:839 [inline]
 __se_sys_fchownat fs/open.c:836 [inline]
 __x64_sys_fchownat+0xb5/0xd0 fs/open.c:836
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f6fdf3812f9
Quoted 9 lines
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 31 1b 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc9b4e42a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000104
RAX: ffffffffffffffda RBX: 00007ffc9b4e42b0 RCX: 00007f6fdf3812f9
RDX: 0000000000000000 RSI: 0000000020000440 RDI: 00000000ffffff9c
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000003932
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffc9b4e42fc
R13: 0000000000000004 R14: 431bde82d7b634db R15: 00007ffc9b4e4330
 </TASK>

#syz test https://github.com/amir73il/linux fsnotify-fixes

author syzbot Tested-by
#11 lore raw
syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Hello,

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

Reported-by [email protected]
Tested-by [email protected]

Tested on:

commit:         e42bb34c fs: relax assertions on failure to encode fil..
git tree:       https://github.com/amir73il/linux fsnotify-fixes
console output: https://syzkaller.appspot.com/x/log.txt?x=10674cf8580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=c9e486c6802437cf
dashboard link: https://syzkaller.appspot.com/bug?extid=ec07f6f5ce62b858579f
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.