* [syzbot] linux-next boot error: general protection fault in add_mtd_device
@ 2022-06-30 9:32 syzbot
2022-07-07 16:05 ` Siddh Raman Pant
2022-07-22 2:34 ` Tetsuo Handa
0 siblings, 2 replies; 11+ messages in thread
From: syzbot @ 2022-06-30 9:32 UTC (permalink / raw)
To: linux-kernel, linux-mtd, linux-next, miquel.raynal, richard, sfr,
syzkaller-bugs, vigneshr
Hello,
syzbot found the following issue on:
HEAD commit: 6cc11d2a1759 Add linux-next specific files for 20220630
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1640f850080000
kernel config: https://syzkaller.appspot.com/x/.config?x=54f75b620e3845dd
dashboard link: https://syzkaller.appspot.com/bug?extid=fe013f55a2814a9e8cfd
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fe013f55a2814a9e8cfd@syzkaller.appspotmail.com
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 240)
io scheduler mq-deadline registered
io scheduler kyber registered
io scheduler bfq registered
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: button: Power Button [PWRF]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: button: Sleep Button [SLPF]
ACPI: \_SB_.LNKC: Enabled at IRQ 11
virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver
ACPI: \_SB_.LNKD: Enabled at IRQ 10
virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver
ACPI: \_SB_.LNKB: Enabled at IRQ 10
virtio-pci 0000:00:06.0: virtio_pci: leaving for legacy driver
virtio-pci 0000:00:07.0: virtio_pci: leaving for legacy driver
N_HDLC line discipline registered with maxframe=4096
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
00:05: ttyS2 at I/O 0x3e8 (irq = 6, base_baud = 115200) is a 16550A
00:06: ttyS3 at I/O 0x2e8 (irq = 7, base_baud = 115200) is a 16550A
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
ACPI: bus type drm_connector registered
[drm] Initialized vgem 1.0.0 20120112 for vgem on minor 0
[drm] Initialized vkms 1.0.0 20180514 for vkms on minor 1
Console: switching to colour frame buffer device 128x48
platform vkms: [drm] fb0: vkmsdrmfb frame buffer device
usbcore: registered new interface driver udl
brd: module loaded
loop: module loaded
zram: Added device: zram0
null_blk: disk nullb0 created
null_blk: module loaded
Guest personality initialized and is inactive
VMCI host device registered (name=vmci, major=10, minor=119)
Initialized host personality
usbcore: registered new interface driver rtsx_usb
usbcore: registered new interface driver viperboard
usbcore: registered new interface driver dln2
usbcore: registered new interface driver pn533_usb
nfcsim 0.2 initialized
usbcore: registered new interface driver port100
usbcore: registered new interface driver nfcmrvl
Loading iSCSI transport class v2.0-870.
scsi host0: Virtio SCSI HBA
st: Version 20160209, fixed bufsize 32768, s/g segs 256
Rounding down aligned max_sectors from 4294967295 to 4294967288
db_root: cannot open: /etc/target
slram: not enough parameters.
general protection fault, probably for non-canonical address 0xdffffc00000000ac: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000560-0x0000000000000567]
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc4-next-20220630-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/18/2022
RIP: 0010:dev_of_node include/linux/device.h:862 [inline]
RIP: 0010:mtd_check_of_node drivers/mtd/mtdcore.c:563 [inline]
RIP: 0010:add_mtd_device+0xbc8/0x1520 drivers/mtd/mtdcore.c:721
Code: 48 81 fd 60 fe ff ff 0f 84 90 fd ff ff e8 b0 10 97 fc 48 8d bd 60 05 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 da 08 00 00 48 8b ad 60 05 00 00 48 85 ed 0f 84
RSP: 0000:ffffc90000067c98 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff88801ebf2000 RCX: 0000000000000000
RDX: 00000000000000ac RSI: ffffffff84e3a650 RDI: 0000000000000560
RBP: 0000000000000000 R08: 0000000000000006 R09: 0000000000000000
R10: ffffffff89c00000 R11: 0000000000000001 R12: ffff88801ebf2004
R13: ffff88801ebf2028 R14: 0000000000000000 R15: 0000000005a00000
FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000000ba8e000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
mtd_device_parse_register+0x50c/0x850 drivers/mtd/mtdcore.c:1032
mtdram_init_device+0x291/0x350 drivers/mtd/devices/mtdram.c:146
init_mtdram+0xe5/0x177 drivers/mtd/devices/mtdram.c:171
do_one_initcall+0xfe/0x650 init/main.c:1300
do_initcall_level init/main.c:1375 [inline]
do_initcalls init/main.c:1391 [inline]
do_basic_setup init/main.c:1410 [inline]
kernel_init_freeable+0x6b1/0x73a init/main.c:1617
kernel_init+0x1a/0x1d0 init/main.c:1506
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:dev_of_node include/linux/device.h:862 [inline]
RIP: 0010:mtd_check_of_node drivers/mtd/mtdcore.c:563 [inline]
RIP: 0010:add_mtd_device+0xbc8/0x1520 drivers/mtd/mtdcore.c:721
Code: 48 81 fd 60 fe ff ff 0f 84 90 fd ff ff e8 b0 10 97 fc 48 8d bd 60 05 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 da 08 00 00 48 8b ad 60 05 00 00 48 85 ed 0f 84
RSP: 0000:ffffc90000067c98 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff88801ebf2000 RCX: 0000000000000000
RDX: 00000000000000ac RSI: ffffffff84e3a650 RDI: 0000000000000560
RBP: 0000000000000000 R08: 0000000000000006 R09: 0000000000000000
R10: ffffffff89c00000 R11: 0000000000000001 R12: ffff88801ebf2004
R13: ffff88801ebf2028 R14: 0000000000000000 R15: 0000000005a00000
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff88823ffff000 CR3: 000000000ba8e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 48 81 fd 60 fe ff ff cmp $0xfffffffffffffe60,%rbp
7: 0f 84 90 fd ff ff je 0xfffffd9d
d: e8 b0 10 97 fc callq 0xfc9710c2
12: 48 8d bd 60 05 00 00 lea 0x560(%rbp),%rdi
19: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
20: fc ff df
23: 48 89 fa mov %rdi,%rdx
26: 48 c1 ea 03 shr $0x3,%rdx
* 2a: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction
2e: 0f 85 da 08 00 00 jne 0x90e
34: 48 8b ad 60 05 00 00 mov 0x560(%rbp),%rbp
3b: 48 85 ed test %rbp,%rbp
3e: 0f .byte 0xf
3f: 84 .byte 0x84
---
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.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-06-30 9:32 [syzbot] linux-next boot error: general protection fault in add_mtd_device syzbot
@ 2022-07-07 16:05 ` Siddh Raman Pant
2022-07-07 16:06 ` syzbot
2022-07-22 2:34 ` Tetsuo Handa
1 sibling, 1 reply; 11+ messages in thread
From: Siddh Raman Pant @ 2022-07-07 16:05 UTC (permalink / raw)
To: syzbot+fe013f55a2814a9e8cfd
Cc: linux-kernel, linux-mtd, linux-next, miquel.raynal, richard, sfr,
syzkaller-bugs, vigneshr
#syz test linux-next master
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-07-07 16:05 ` Siddh Raman Pant
@ 2022-07-07 16:06 ` syzbot
2022-07-07 16:09 ` Siddh Raman Pant
0 siblings, 1 reply; 11+ messages in thread
From: syzbot @ 2022-07-07 16:06 UTC (permalink / raw)
To: Siddh Raman Pant
Cc: code, linux-kernel, linux-mtd, linux-next, miquel.raynal,
richard, sfr, syzkaller-bugs, vigneshr
> #syz test linux-next master
"linux-next" does not look like a valid git repo address.
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-07-07 16:06 ` syzbot
@ 2022-07-07 16:09 ` Siddh Raman Pant
2022-07-07 16:28 ` syzbot
0 siblings, 1 reply; 11+ messages in thread
From: Siddh Raman Pant @ 2022-07-07 16:09 UTC (permalink / raw)
To: syzbot
Cc: linux-kernel, linux-mtd, linux-next, miquel.raynal, richard, sfr,
syzkaller-bugs, vigneshr
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-07-07 16:09 ` Siddh Raman Pant
@ 2022-07-07 16:28 ` syzbot
0 siblings, 0 replies; 11+ messages in thread
From: syzbot @ 2022-07-07 16:28 UTC (permalink / raw)
To: code, linux-kernel, linux-mtd, linux-next, miquel.raynal,
richard, sfr, syzkaller-bugs, vigneshr
Hello,
syzbot tried to test the proposed patch but the build/boot failed:
6.6.0
[ 3.293811][ T1] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 3.296985][ T1] FS-Cache: Loaded
[ 3.299821][ T1] CacheFiles: Loaded
[ 3.301735][ T1] TOMOYO: 2.6.0
[ 3.303022][ T1] Mandatory Access Control activated.
[ 3.308387][ T1] AppArmor: AppArmor Filesystem Enabled
[ 3.310932][ T1] pnp: PnP ACPI init
[ 3.333081][ T1] pnp: PnP ACPI: found 7 devices
[ 3.387288][ T1] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 3.391662][ T1] NET: Registered PF_INET protocol family
[ 3.397452][ T1] IP idents hash table entries: 131072 (order: 8, 1048576 bytes, vmalloc)
[ 3.412428][ T1] tcp_listen_portaddr_hash hash table entries: 4096 (order: 6, 294912 bytes, vmalloc)
[ 3.416351][ T1] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, vmalloc)
[ 3.421360][ T1] TCP established hash table entries: 65536 (order: 7, 524288 bytes, vmalloc)
[ 3.430604][ T1] TCP bind hash table entries: 65536 (order: 10, 4718592 bytes, vmalloc hugepage)
[ 3.438876][ T1] TCP: Hash tables configured (established 65536 bind 65536)
[ 3.444254][ T1] MPTCP token hash table entries: 8192 (order: 7, 720896 bytes, vmalloc)
[ 3.450021][ T1] UDP hash table entries: 4096 (order: 7, 655360 bytes, vmalloc)
[ 3.455480][ T1] UDP-Lite hash table entries: 4096 (order: 7, 655360 bytes, vmalloc)
[ 3.459868][ T1] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 3.464349][ T1] RPC: Registered named UNIX socket transport module.
[ 3.466551][ T1] RPC: Registered udp transport module.
[ 3.468052][ T1] RPC: Registered tcp transport module.
[ 3.469630][ T1] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 3.474445][ T1] NET: Registered PF_XDP protocol family
[ 3.476136][ T1] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window]
[ 3.478533][ T1] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window]
[ 3.480808][ T1] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
[ 3.483102][ T1] pci_bus 0000:00: resource 7 [mem 0xc0000000-0xfebfefff window]
[ 3.486449][ T1] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[ 3.488875][ T1] PCI: CLS 0 bytes, default 64
[ 3.490261][ T1] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 3.492502][ T1] software IO TLB: mapped [mem 0x00000000b5a00000-0x00000000b9a00000] (64MB)
[ 3.495480][ T1] ACPI: bus type thunderbolt registered
[ 3.509757][ T57] kworker/u4:1 (57) used greatest stack depth: 27256 bytes left
[ 3.511725][ T1] RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl timer
[ 3.539645][ T1] kvm: already loaded vendor module 'kvm_intel'
[ 3.541703][ T1] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1fb700c3c76, max_idle_ns: 440795286388 ns
[ 3.545330][ T1] clocksource: Switched to clocksource tsc
[ 3.555572][ T62] kworker/u4:4 (62) used greatest stack depth: 26864 bytes left
[ 7.007347][ T1] Initialise system trusted keyrings
[ 7.010222][ T1] workingset: timestamp_bits=40 max_order=21 bucket_order=0
[ 7.053672][ T1] zbud: loaded
[ 7.062452][ T1] DLM installed
[ 7.071357][ T1] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 7.083415][ T1] NFS: Registering the id_resolver key type
[ 7.084569][ T1] Key type id_resolver registered
[ 7.085956][ T1] Key type id_legacy registered
[ 7.087430][ T1] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 7.088957][ T1] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[ 7.090898][ T1] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 7.099997][ T1] Key type cifs.spnego registered
[ 7.101124][ T1] Key type cifs.idmap registered
[ 7.102589][ T1] ntfs: driver 2.1.32 [Flags: R/W].
[ 7.104795][ T1] ntfs3: Max link count 4000
[ 7.105478][ T1] ntfs3: Enabled Linux POSIX ACLs support
[ 7.106598][ T1] ntfs3: Read-only LZX/Xpress compression included
[ 7.110177][ T1] efs: 1.0a - http://aeschi.ch.eu.org/efs/
[ 7.112037][ T1] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
[ 7.117328][ T1] romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
[ 7.119672][ T1] QNX4 filesystem 0.2.3 registered.
[ 7.121322][ T1] qnx6: QNX6 filesystem 1.0.0 registered.
[ 7.123668][ T1] fuse: init (API version 7.36)
[ 7.128698][ T1] orangefs_debugfs_init: called with debug mask: :none: :0:
[ 7.130627][ T1] orangefs_init: module version upstream loaded
[ 7.132582][ T1] JFS: nTxBlock = 8192, nTxLock = 65536
[ 7.151005][ T1] SGI XFS with ACLs, security attributes, realtime, quota, fatal assert, debug enabled
[ 7.165385][ T1] 9p: Installing v9fs 9p2000 file system support
[ 7.168114][ T1] NILFS version 2 loaded
[ 7.168946][ T1] befs: version: 0.9.3
[ 7.171224][ T1] ocfs2: Registered cluster interface o2cb
[ 7.172474][ T1] ocfs2: Registered cluster interface user
[ 7.174608][ T1] OCFS2 User DLM kernel interface loaded
[ 7.186651][ T1] gfs2: GFS2 installed
[ 7.200575][ T1] ceph: loaded (mds proto 32)
[ 7.214141][ T1] NET: Registered PF_ALG protocol family
[ 7.215457][ T1] xor: automatically using best checksumming function avx
[ 7.216575][ T1] async_tx: api initialized (async)
[ 7.217530][ T1] Key type asymmetric registered
[ 7.218239][ T1] Asymmetric key parser 'x509' registered
[ 7.219470][ T1] Asymmetric key parser 'pkcs8' registered
[ 7.220454][ T1] Key type pkcs7_test registered
[ 7.224877][ T1] alg: self-tests for CTR-KDF (hmac(sha256)) passed
[ 7.226248][ T1] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 240)
[ 7.228234][ T1] io scheduler mq-deadline registered
[ 7.229517][ T1] io scheduler kyber registered
[ 7.231202][ T1] io scheduler bfq registered
[ 7.246749][ T1] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[ 7.259853][ T1] ACPI: button: Power Button [PWRF]
[ 7.262507][ T1] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
[ 7.265778][ T1] ACPI: button: Sleep Button [SLPF]
[ 7.292165][ T1] ACPI: \_SB_.LNKC: Enabled at IRQ 11
[ 7.293783][ T1] virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver
[ 7.313174][ T1] ACPI: \_SB_.LNKD: Enabled at IRQ 10
[ 7.314393][ T1] virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver
[ 7.333582][ T1] ACPI: \_SB_.LNKB: Enabled at IRQ 10
[ 7.334602][ T1] virtio-pci 0000:00:06.0: virtio_pci: leaving for legacy driver
[ 7.348953][ T1] virtio-pci 0000:00:07.0: virtio_pci: leaving for legacy driver
[ 7.771530][ T1] N_HDLC line discipline registered with maxframe=4096
[ 7.772933][ T1] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 7.774539][ T1] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 7.783403][ T1] 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[ 7.791265][ T1] 00:05: ttyS2 at I/O 0x3e8 (irq = 6, base_baud = 115200) is a 16550A
[ 7.797093][ T1] 00:06: ttyS3 at I/O 0x2e8 (irq = 7, base_baud = 115200) is a 16550A
[ 7.809304][ T1] Non-volatile memory driver v1.3
[ 7.827944][ T1] Linux agpgart interface v0.103
[ 7.833603][ T1] ACPI: bus type drm_connector registered
[ 7.838434][ T1] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 0
[ 7.845071][ T1] [drm] Initialized vkms 1.0.0 20180514 for vkms on minor 1
[ 7.907391][ T1] Console: switching to colour frame buffer device 128x48
[ 7.925767][ T1] platform vkms: [drm] fb0: vkmsdrmfb frame buffer device
[ 7.927589][ T1] usbcore: registered new interface driver udl
[ 7.989754][ T1] brd: module loaded
[ 8.050181][ T1] loop: module loaded
[ 8.135078][ T1] zram: Added device: zram0
[ 8.143367][ T1] null_blk: disk nullb0 created
[ 8.144480][ T1] null_blk: module loaded
[ 8.145538][ T1] Guest personality initialized and is inactive
[ 8.147216][ T1] VMCI host device registered (name=vmci, major=10, minor=119)
[ 8.148573][ T1] Initialized host personality
[ 8.149563][ T1] usbcore: registered new interface driver rtsx_usb
[ 8.151595][ T1] usbcore: registered new interface driver viperboard
[ 8.153227][ T1] usbcore: registered new interface driver dln2
[ 8.154829][ T1] usbcore: registered new interface driver pn533_usb
[ 8.161056][ T1] nfcsim 0.2 initialized
[ 8.162049][ T1] usbcore: registered new interface driver port100
[ 8.163368][ T1] usbcore: registered new interface driver nfcmrvl
[ 8.167580][ T1] Loading iSCSI transport class v2.0-870.
[ 8.202542][ T1] scsi host0: Virtio SCSI HBA
[ 8.248257][ T1] st: Version 20160209, fixed bufsize 32768, s/g segs 256
[ 8.251625][ T46] scsi 0:0:1:0: Direct-Access Google PersistentDisk 1 PQ: 0 ANSI: 6
[ 8.289244][ T1] Rounding down aligned max_sectors from 4294967295 to 4294967288
[ 8.291872][ T1] db_root: cannot open: /etc/target
[ 8.294506][ T1] slram: not enough parameters.
[ 8.301140][ T1] general protection fault, probably for non-canonical address 0xdffffc00000000ac: 0000 [#1] PREEMPT SMP KASAN
[ 8.303611][ T1] KASAN: null-ptr-deref in range [0x0000000000000560-0x0000000000000567]
[ 8.305651][ T1] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc5-next-20220707-syzkaller #0
[ 8.308417][ T1] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/29/2022
[ 8.308417][ T1] RIP: 0010:add_mtd_device+0xbc8/0x1520
[ 8.308417][ T1] Code: 48 81 fd 60 fe ff ff 0f 84 90 fd ff ff e8 30 9a 95 fc 48 8d bd 60 05 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 da 08 00 00 48 8b ad 60 05 00 00 48 85 ed 0f 84
[ 8.308417][ T1] RSP: 0000:ffffc90000067c98 EFLAGS: 00010206
[ 8.308417][ T1] RAX: dffffc0000000000 RBX: ffff8881472e2000 RCX: 0000000000000000
[ 8.308417][ T1] RDX: 00000000000000ac RSI: ffffffff84e5ed10 RDI: 0000000000000560
[ 8.308417][ T1] RBP: 0000000000000000 R08: 0000000000000006 R09: 0000000000000000
[ 8.308417][ T1] R10: ffffffff89e00000 R11: 0000000000000000 R12: ffff8881472e2004
[ 8.308417][ T1] R13: ffff8881472e2028 R14: 0000000000000000 R15: 0000000005a00000
[ 8.308417][ T1] FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
[ 8.308417][ T1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8.308417][ T1] CR2: 0000000000000000 CR3: 000000000bc8e000 CR4: 00000000003506e0
[ 8.308417][ T1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8.308417][ T1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 8.308417][ T1] Call Trace:
[ 8.308417][ T1] <TASK>
[ 8.308417][ T1] ? del_mtd_partitions+0x50/0x50
[ 8.308417][ T1] ? lockdep_init_map_type+0x21a/0x7f0
[ 8.308417][ T1] ? mtd_erase+0x8e0/0x8e0
[ 8.308417][ T1] ? lockdep_init_map_type+0x21a/0x7f0
[ 8.308417][ T1] ? __raw_spin_lock_init+0x36/0x110
[ 8.308417][ T1] mtd_device_parse_register+0x50c/0x850
[ 8.308417][ T1] mtdram_init_device+0x291/0x350
[ 8.308417][ T1] ? init_phram+0x99/0x99
[ 8.308417][ T1] init_mtdram+0xe5/0x177
[ 8.308417][ T1] ? init_phram+0x99/0x99
[ 8.308417][ T1] do_one_initcall+0xfe/0x650
[ 8.308417][ T1] ? trace_event_raw_event_initcall_level+0x1f0/0x1f0
[ 8.308417][ T1] ? parameq+0x120/0x170
[ 8.308417][ T1] kernel_init_freeable+0x6b1/0x73a
[ 8.308417][ T1] ? rest_init+0x270/0x270
[ 8.308417][ T1] kernel_init+0x1a/0x1d0
[ 8.308417][ T1] ? rest_init+0x270/0x270
[ 8.308417][ T1] ret_from_fork+0x1f/0x30
[ 8.308417][ T1] </TASK>
[ 8.308417][ T1] Modules linked in:
[ 8.354639][ T1] ---[ end trace 0000000000000000 ]---
[ 8.356288][ T1] RIP: 0010:add_mtd_device+0xbc8/0x1520
[ 8.358068][ T1] Code: 48 81 fd 60 fe ff ff 0f 84 90 fd ff ff e8 30 9a 95 fc 48 8d bd 60 05 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 da 08 00 00 48 8b ad 60 05 00 00 48 85 ed 0f 84
[ 8.364455][ T1] RSP: 0000:ffffc90000067c98 EFLAGS: 00010206
[ 8.366307][ T1] RAX: dffffc0000000000 RBX: ffff8881472e2000 RCX: 0000000000000000
[ 8.368860][ T1] RDX: 00000000000000ac RSI: ffffffff84e5ed10 RDI: 0000000000000560
[ 8.371267][ T1] RBP: 0000000000000000 R08: 0000000000000006 R09: 0000000000000000
[ 8.373529][ T1] R10: ffffffff89e00000 R11: 0000000000000000 R12: ffff8881472e2004
[ 8.376204][ T1] R13: ffff8881472e2028 R14: 0000000000000000 R15: 0000000005a00000
[ 8.378489][ T1] FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
[ 8.381365][ T1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8.383439][ T1] CR2: ffff88823ffff000 CR3: 000000000bc8e000 CR4: 00000000003506f0
[ 8.385780][ T1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8.388324][ T1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 8.390899][ T1] Kernel panic - not syncing: Fatal exception
[ 8.393182][ T1] Kernel Offset: disabled
[ 8.394024][ T1] Rebooting in 86400 seconds..
syzkaller build log:
go env (err=<nil>)
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/syzkaller/.cache/go-build"
GOENV="/syzkaller/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/syzkaller/jobs/linux/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/syzkaller/jobs/linux/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/syzkaller/jobs/linux/gopath/src/github.com/google/syzkaller/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build360636327=/tmp/go-build -gno-record-gcc-switches"
git status (err=<nil>)
HEAD detached at bff65f44b
nothing to commit, working tree clean
go list -f '{{.Stale}}' ./sys/syz-sysgen | grep -q false || go install ./sys/syz-sysgen
make .descriptions
bin/syz-sysgen
touch .descriptions
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=bff65f44b47bd73f56c3d6a5c3899de5f5775136 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20220704-135716'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-fuzzer github.com/google/syzkaller/syz-fuzzer
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=bff65f44b47bd73f56c3d6a5c3899de5f5775136 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20220704-135716'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-execprog github.com/google/syzkaller/tools/syz-execprog
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=bff65f44b47bd73f56c3d6a5c3899de5f5775136 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20220704-135716'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-stress github.com/google/syzkaller/tools/syz-stress
mkdir -p ./bin/linux_amd64
gcc -o ./bin/linux_amd64/syz-executor executor/executor.cc \
-m64 -O2 -pthread -Wall -Werror -Wparentheses -Wunused-const-variable -Wframe-larger-than=16384 -Wno-stringop-overflow -Wno-array-bounds -Wno-format-overflow -static-pie -fpermissive -w -DGOOS_linux=1 -DGOARCH_amd64=1 \
-DHOSTGOOS_linux=1 -DGIT_REVISION=\"bff65f44b47bd73f56c3d6a5c3899de5f5775136\"
Error text is too large and was truncated, full error text is at:
https://syzkaller.appspot.com/x/error.txt?x=1521cd5c080000
Tested on:
commit: 75d7bf5e Add linux-next specific files for 20220707
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
kernel config: https://syzkaller.appspot.com/x/.config?x=12690a05d4f2fc33
dashboard link: https://syzkaller.appspot.com/bug?extid=fe013f55a2814a9e8cfd
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
Note: no patches were applied.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-06-30 9:32 [syzbot] linux-next boot error: general protection fault in add_mtd_device syzbot
2022-07-07 16:05 ` Siddh Raman Pant
@ 2022-07-22 2:34 ` Tetsuo Handa
2022-07-22 2:51 ` Christian Marangi
2022-07-22 4:31 ` Vanessa Page
1 sibling, 2 replies; 11+ messages in thread
From: Tetsuo Handa @ 2022-07-22 2:34 UTC (permalink / raw)
To: Christian Marangi, Miquel Raynal; +Cc: linux-mtd
mtd_check_of_node() was added by commit ad9b10d1eaada169 ("mtd: core:
introduce of support for dynamic partitions").
I guess that sometimes (depending on probe timing) mtd->parent is NULL.
Please check what mtd->parent == NULL means.
+ /* Check if a partitions node exist */
+ parent = mtd->parent;
+ parent_dn = dev_of_node(&parent->dev);
On 2022/06/30 18:32, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 6cc11d2a1759 Add linux-next specific files for 20220630
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1640f850080000
> kernel config: https://syzkaller.appspot.com/x/.config?x=54f75b620e3845dd
> dashboard link: https://syzkaller.appspot.com/bug?extid=fe013f55a2814a9e8cfd
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+fe013f55a2814a9e8cfd@syzkaller.appspotmail.com
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-07-22 2:34 ` Tetsuo Handa
@ 2022-07-22 2:51 ` Christian Marangi
2022-07-24 1:33 ` Tetsuo Handa
2022-07-22 4:31 ` Vanessa Page
1 sibling, 1 reply; 11+ messages in thread
From: Christian Marangi @ 2022-07-22 2:51 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: Miquel Raynal, linux-mtd
On Fri, Jul 22, 2022 at 11:34:57AM +0900, Tetsuo Handa wrote:
> mtd_check_of_node() was added by commit ad9b10d1eaada169 ("mtd: core:
> introduce of support for dynamic partitions").
>
> I guess that sometimes (depending on probe timing) mtd->parent is NULL.
> Please check what mtd->parent == NULL means.
>
> + /* Check if a partitions node exist */
> + parent = mtd->parent;
> + parent_dn = dev_of_node(&parent->dev);
>
Currently there is thix [1].
Anyway you comment means a device may probe defer and have the parent
still set to NULL? How can we check that?
Return PROBE_DEFER always when no mtd parent is found?
[1] https://patchwork.ozlabs.org/project/linux-mtd/patch/20220703095631.16508-1-ansuelsmth@gmail.com/
> On 2022/06/30 18:32, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 6cc11d2a1759 Add linux-next specific files for 20220630
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1640f850080000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=54f75b620e3845dd
> > dashboard link: https://syzkaller.appspot.com/bug?extid=fe013f55a2814a9e8cfd
> > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+fe013f55a2814a9e8cfd@syzkaller.appspotmail.com
--
Ansuel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-07-22 2:34 ` Tetsuo Handa
2022-07-22 2:51 ` Christian Marangi
@ 2022-07-22 4:31 ` Vanessa Page
1 sibling, 0 replies; 11+ messages in thread
From: Vanessa Page @ 2022-07-22 4:31 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: Christian Marangi, Miquel Raynal, linux-mtd
And yet you still keep sending them.
> On Jul 21, 2022, at 10:37 PM, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> mtd_check_of_node() was added by commit ad9b10d1eaada169 ("mtd: core:
> introduce of support for dynamic partitions").
>
> I guess that sometimes (depending on probe timing) mtd->parent is NULL.
> Please check what mtd->parent == NULL means.
>
> + /* Check if a partitions node exist */
> + parent = mtd->parent;
> + parent_dn = dev_of_node(&parent->dev);
>
>> On 2022/06/30 18:32, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit: 6cc11d2a1759 Add linux-next specific files for 20220630
>> git tree: linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1640f850080000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=54f75b620e3845dd
>> dashboard link: https://syzkaller.appspot.com/bug?extid=fe013f55a2814a9e8cfd
>> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+fe013f55a2814a9e8cfd@syzkaller.appspotmail.com
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-07-22 2:51 ` Christian Marangi
@ 2022-07-24 1:33 ` Tetsuo Handa
2022-07-24 1:37 ` Vanessa Page
2022-07-24 18:21 ` Linus Torvalds
0 siblings, 2 replies; 11+ messages in thread
From: Tetsuo Handa @ 2022-07-24 1:33 UTC (permalink / raw)
To: Christian Marangi; +Cc: Miquel Raynal, linux-mtd, Linus Torvalds, Dmitry Vyukov
On 2022/07/22 11:51, Christian Marangi wrote:
> On Fri, Jul 22, 2022 at 11:34:57AM +0900, Tetsuo Handa wrote:
>> mtd_check_of_node() was added by commit ad9b10d1eaada169 ("mtd: core:
>> introduce of support for dynamic partitions").
>>
>> I guess that sometimes (depending on probe timing) mtd->parent is NULL.
>> Please check what mtd->parent == NULL means.
>>
>> + /* Check if a partitions node exist */
>> + parent = mtd->parent;
>> + parent_dn = dev_of_node(&parent->dev);
>>
>
> Currently there is thix [1].
OK. Then for now can we try that "prevent the crash" patch (and defer
examining the cause of being NULL) ?
>
> Anyway you comment means a device may probe defer and have the parent
> still set to NULL? How can we check that?
My comment is just a guess. I have zero experience in this area.
If this problem is not timing dependent, syzbot would have already
reported this problem for thousands times. But since syzbot reported
this problem only 84 times in 23 days, I think that this problem is
timing dependent (i.e. some race condition).
>
> Return PROBE_DEFER always when no mtd parent is found?
We could try tracing what value is assigned to mtd->parent, by
introducing a validation wrapper function (which validates that
the address is a valid kernel address) like
----------------------------------------
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 348acf2558f3..6b1626776b95 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -91,4 +91,12 @@ static inline __must_check bool check_data_corruption(bool v) { return v; }
corruption; \
}))
+extern void check_valid_kernel_ptr(void *arg, const char *name);
+#define valid_kernel_ptr(ptr) \
+ ({ \
+ typeof(ptr) tmp = (ptr); \
+ check_valid_kernel_ptr(tmp, __stringify(ptr)); \
+ tmp; \
+ })
+
#endif /* _LINUX_BUG_H */
diff --git a/lib/bug.c b/lib/bug.c
index c223a2575b72..6555766134cf 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -231,3 +231,10 @@ void generic_bug_clear_once(void)
clear_once_table(__start___bug_table, __stop___bug_table);
}
+
+void check_valid_kernel_ptr(void *arg, const char *name)
+{
+ WARN(!arg, "%s is NULL\n", name);
+ WARN(IS_ERR(arg), "%s is %pe\n", name, arg);
+}
+EXPORT_SYMBOL(check_valid_kernel_ptr);
----------------------------------------
and wrapping all locations that modifies mtd->parent like
----------------------------------------
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index d442fa94c872..2e81539ddfd8 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -81,9 +81,9 @@ static struct mtd_info *allocate_partition(struct mtd_info *parent,
* distinguish between the parent and its partitions in sysfs.
*/
child->dev.parent = IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER) || mtd_is_partition(parent) ?
- &parent->dev : parent->dev.parent;
+ &parent->dev : valid_kernel_ptr(parent->dev.parent);
child->dev.of_node = part->of_node;
- child->parent = parent;
+ child->parent = valid_kernel_ptr(parent);
child->part.offset = part->offset;
INIT_LIST_HEAD(&child->partitions);
----------------------------------------
. If none of all wrapped assignments triggers, we would need to check
locations that explicitly assign NULL. (That is, possibility of hitting
a race that the parent was once non-NULL but then became NULL due to
error or cleanup path.)
We can add some CONFIG_ option for controlling whether check_valid_kernel_ptr()
should become
#define valid_kernel_ptr(ptr) (ptr)
so that we can avoid overhead when this problem if fixed.
Linus, can we have macros like valid_kernel_ptr() ? Macros like
valid_kernel_ptr(), valid_kernel_ptr_or_null(), valid_kernel_ptr_or_err() can
serve for documentation purpose without runtime cost for non-debug builds.
>
> [1] https://patchwork.ozlabs.org/project/linux-mtd/patch/20220703095631.16508-1-ansuelsmth@gmail.com/
>
>> On 2022/06/30 18:32, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit: 6cc11d2a1759 Add linux-next specific files for 20220630
>>> git tree: linux-next
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1640f850080000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=54f75b620e3845dd
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=fe013f55a2814a9e8cfd
>>> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>> Reported-by: syzbot+fe013f55a2814a9e8cfd@syzkaller.appspotmail.com
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-07-24 1:33 ` Tetsuo Handa
@ 2022-07-24 1:37 ` Vanessa Page
2022-07-24 18:21 ` Linus Torvalds
1 sibling, 0 replies; 11+ messages in thread
From: Vanessa Page @ 2022-07-24 1:37 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Christian Marangi, Miquel Raynal, linux-mtd, Linus Torvalds,
Dmitry Vyukov
You can’t prevent it dumb ass
Sent from my iPhone
> On Jul 23, 2022, at 9:36 PM, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2022/07/22 11:51, Christian Marangi wrote:
>>> On Fri, Jul 22, 2022 at 11:34:57AM +0900, Tetsuo Handa wrote:
>>> mtd_check_of_node() was added by commit ad9b10d1eaada169 ("mtd: core:
>>> introduce of support for dynamic partitions").
>>>
>>> I guess that sometimes (depending on probe timing) mtd->parent is NULL.
>>> Please check what mtd->parent == NULL means.
>>>
>>> + /* Check if a partitions node exist */
>>> + parent = mtd->parent;
>>> + parent_dn = dev_of_node(&parent->dev);
>>>
>>
>> Currently there is thix [1].
>
> OK. Then for now can we try that "prevent the crash" patch (and defer
> examining the cause of being NULL) ?
>
>>
>> Anyway you comment means a device may probe defer and have the parent
>> still set to NULL? How can we check that?
>
> My comment is just a guess. I have zero experience in this area.
>
> If this problem is not timing dependent, syzbot would have already
> reported this problem for thousands times. But since syzbot reported
> this problem only 84 times in 23 days, I think that this problem is
> timing dependent (i.e. some race condition).
>
>>
>> Return PROBE_DEFER always when no mtd parent is found?
>
> We could try tracing what value is assigned to mtd->parent, by
> introducing a validation wrapper function (which validates that
> the address is a valid kernel address) like
>
> ----------------------------------------
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index 348acf2558f3..6b1626776b95 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -91,4 +91,12 @@ static inline __must_check bool check_data_corruption(bool v) { return v; }
> corruption; \
> }))
>
> +extern void check_valid_kernel_ptr(void *arg, const char *name);
> +#define valid_kernel_ptr(ptr) \
> + ({ \
> + typeof(ptr) tmp = (ptr); \
> + check_valid_kernel_ptr(tmp, __stringify(ptr)); \
> + tmp; \
> + })
> +
> #endif /* _LINUX_BUG_H */
> diff --git a/lib/bug.c b/lib/bug.c
> index c223a2575b72..6555766134cf 100644
> --- a/lib/bug.c
> +++ b/lib/bug.c
> @@ -231,3 +231,10 @@ void generic_bug_clear_once(void)
>
> clear_once_table(__start___bug_table, __stop___bug_table);
> }
> +
> +void check_valid_kernel_ptr(void *arg, const char *name)
> +{
> + WARN(!arg, "%s is NULL\n", name);
> + WARN(IS_ERR(arg), "%s is %pe\n", name, arg);
> +}
> +EXPORT_SYMBOL(check_valid_kernel_ptr);
> ----------------------------------------
>
> and wrapping all locations that modifies mtd->parent like
>
> ----------------------------------------
> diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
> index d442fa94c872..2e81539ddfd8 100644
> --- a/drivers/mtd/mtdpart.c
> +++ b/drivers/mtd/mtdpart.c
> @@ -81,9 +81,9 @@ static struct mtd_info *allocate_partition(struct mtd_info *parent,
> * distinguish between the parent and its partitions in sysfs.
> */
> child->dev.parent = IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER) || mtd_is_partition(parent) ?
> - &parent->dev : parent->dev.parent;
> + &parent->dev : valid_kernel_ptr(parent->dev.parent);
> child->dev.of_node = part->of_node;
> - child->parent = parent;
> + child->parent = valid_kernel_ptr(parent);
> child->part.offset = part->offset;
> INIT_LIST_HEAD(&child->partitions);
>
> ----------------------------------------
>
> . If none of all wrapped assignments triggers, we would need to check
> locations that explicitly assign NULL. (That is, possibility of hitting
> a race that the parent was once non-NULL but then became NULL due to
> error or cleanup path.)
>
> We can add some CONFIG_ option for controlling whether check_valid_kernel_ptr()
> should become
>
> #define valid_kernel_ptr(ptr) (ptr)
>
> so that we can avoid overhead when this problem if fixed.
>
> Linus, can we have macros like valid_kernel_ptr() ? Macros like
> valid_kernel_ptr(), valid_kernel_ptr_or_null(), valid_kernel_ptr_or_err() can
> serve for documentation purpose without runtime cost for non-debug builds.
>
>>
>> [1] https://patchwork.ozlabs.org/project/linux-mtd/patch/20220703095631.16508-1-ansuelsmth@gmail.com/
>>
>>> On 2022/06/30 18:32, syzbot wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following issue on:
>>>>
>>>> HEAD commit: 6cc11d2a1759 Add linux-next specific files for 20220630
>>>> git tree: linux-next
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1640f850080000
>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=54f75b620e3845dd
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=fe013f55a2814a9e8cfd
>>>> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>>>>
>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>> Reported-by: syzbot+fe013f55a2814a9e8cfd@syzkaller.appspotmail.com
>>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] linux-next boot error: general protection fault in add_mtd_device
2022-07-24 1:33 ` Tetsuo Handa
2022-07-24 1:37 ` Vanessa Page
@ 2022-07-24 18:21 ` Linus Torvalds
1 sibling, 0 replies; 11+ messages in thread
From: Linus Torvalds @ 2022-07-24 18:21 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: Christian Marangi, Miquel Raynal, linux-mtd, Dmitry Vyukov
On Sat, Jul 23, 2022 at 6:34 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> Linus, can we have macros like valid_kernel_ptr() ? Macros like
> valid_kernel_ptr(), valid_kernel_ptr_or_null(), valid_kernel_ptr_or_err() can
> serve for documentation purpose without runtime cost for non-debug builds.
No. We have IS_ERR_OR_NULL(), but validating a kernel pointer in
general is pretty much impossible.
You can try to just dereference it - and it's even fairly efficient if
the exception case is supposed to be very rare.
But even that is not really "safe", in that it can cause IO accesses
etc. Plus it fundamentally cannot catch the likely case - the pointer
"works", but it's simply stale and doesn't point to the right data.
And honestly, even if the pointer doesn't actually "work" as a
pointer, you are actually much better off taking the exception at that
point, and getting an oops, and just FIXING THE BUG instead.
Having some model where "this pointer fails, so I'll just do something
else" is completely and utterly wrong.
It's bad for debugging, and it's impossible for any real use.
So the whole notion of "is this pointer safe" is garbage.
The only way to make sure a pointer is safe is to just make sure it's
initialized properly. Once you start using random pointers, all bets
are off, and no amount of "let's verify this" will ever help at all.
It will only hurt.
Linus
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-07-24 18:22 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-30 9:32 [syzbot] linux-next boot error: general protection fault in add_mtd_device syzbot
2022-07-07 16:05 ` Siddh Raman Pant
2022-07-07 16:06 ` syzbot
2022-07-07 16:09 ` Siddh Raman Pant
2022-07-07 16:28 ` syzbot
2022-07-22 2:34 ` Tetsuo Handa
2022-07-22 2:51 ` Christian Marangi
2022-07-24 1:33 ` Tetsuo Handa
2022-07-24 1:37 ` Vanessa Page
2022-07-24 18:21 ` Linus Torvalds
2022-07-22 4:31 ` Vanessa Page
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).