Re: Kernel Crash: iio_dummy: General protection fault and null-ptr-deref in iio_simple_dummy_events_register

[David Lechner <dlechner@baylibre.com>]

On 3/25/25 10:26 PM, Waseem Riaz wrote:
> Hi,
> 
> I'm encountering a kernel crash when trying to create a dummy device
> in the IIO subsystem using configfs. This occurs when executing:
> 
>     mkdir /config/iio/devices/dummy/my_dummy_device
> 
> The error manifests as a general protection fault with KASAN reporting
> a null pointer dereference. The crash occurs in
> __x86_indirect_thunk_r13 during iio_simple_dummy_events_register.
> 
> ## Environment
> - Kernel version: 6.14.0-rc1-g2014c95afece
> - Architecture: x86_64
> - Testing environment: QEMU VM
> 
> ## Steps to reproduce
> 1. Build the kernel with CONFIG_IIO_CONFIGFS,
> CONFIG_IIO_SIMPLE_DUMMY=m, and CONFIG_IIO_DUMMY_EVGEN=m
> 2. Start qemu with the kernel and bullseye image with the following command
>          qemu-system-x86_64 \
>         -m 2G \
>         -smp 2 \
>         -kernel iio/arch/x86/boot/bzImage \
>         -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
>         -drive file= image/bullseye.img,format=raw \
>         -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
>         -net nic,model=e1000 \
>         -enable-kvm \
>         -nographic \
>         -pidfile vm.pid \
>         2>&1 | tee vm.log
> 3. Mount configfs to /config
>          mount -t configfs none /config
> 4. Load the modules in order
> 5. Create a dummy device in /config/iio/devices/dummy/

Thanks for the detailed bug report. :-)

> 
> ## Crash Log
> [   99.037889] Oops: general protection fault, probably for
> non-canonical address 0xdffffc0000000000: 000I
> [   99.044568] KASAN: null-ptr-deref in range
> [0x0000000000000000-0x0000000000000007]
> [   99.046591] CPU: 1 UID: 0 PID: 236 Comm: mkdir Not tainted
> 6.14.0-rc1-g2014c95afece #8
> [   99.048575] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Arch Linux 1.16.3-1-1 04/01/204
> [   99.050516] RIP: 0010:__x86_indirect_thunk_r13+0xa/0x20
> [   99.051818] Code: e8 01 00 00 00 cc 4c 89 24 24 c3 cc cc cc cc 90
> 66 66 2e 0f 1f 84 00 00 00 00 00 0f 0
> [   99.056765] RSP: 0018:ffff8880035a7bd0 EFLAGS: 00010246
> [   99.057870] RAX: dffffc0000000000 RBX: ffff888008687828 RCX: 1ffff11000725946
> [   99.059311] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888008686000
> [   99.060580] RBP: ffff88800392ca00 R08: 0000000000000001 R09: ffffed10006b4f78
> [   99.061419] R10: ffff8880035a7bc7 R11: ffffffff8ca58570 R12: 0000000000000000
> [   99.062269] R13: 65645f7974743a72 R14: ffffffff8c5e5420 R15: ffff888008687870
> [   99.063254] FS:  00007fe43adc2400(0000) GS:ffff88806d300000(0000)
> knlGS:0000000000000000
> [   99.064734] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   99.065649] CR2: 000056088dfb66c0 CR3: 0000000001fc2000 CR4: 00000000000006f0
> [   99.066599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   99.067627] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [   99.068726] Call Trace:
> [   99.069106]  <TASK>
> [   99.069442]  ? __die_body.cold+0x19/0x29
> [   99.069862]  ? die_addr+0x41/0x70
> [   99.070222]  ? exc_general_protection+0x13f/0x210
> [   99.071005]  ? asm_exc_general_protection+0x26/0x30
> [   99.071809]  ? __pfx_irq_sim_request_resources+0x10/0x10
> [   99.072639]  ? kasan_save_stack+0x30/0x50
> [   99.073263]  ? __x86_indirect_thunk_r13+0xa/0x20
> [   99.074055]  ? irq_sim_request_resources+0xf3/0x160
> [   99.074871]  ? setup_irq_thread+0xfa/0x180
> [   99.075576]  ? __setup_irq+0x747/0x1a20
> [   99.076207]  ? kasan_save_track+0x14/0x30
> [   99.077482]  ? request_threaded_irq+0x20b/0x350
> [   99.077954]  ? __pfx_iio_simple_dummy_event_handler+0x10/0x10 [iio_dummy]
> [   99.078647]  ? iio_simple_dummy_events_register+0x104/0x1a0 [iio_dummy]
> [   99.079356]  ? kstrdup+0x8b/0xb0
> [   99.079991]  ? iio_dummy_probe+0x3d7/0x5c0 [iio_dummy]

Apparently, the IRQ is already triggered and the handler is called
before the indio_dev is fully registered.

We should probably be passing the IRQF_NO_AUTOEN flag when requesting
the IRQ and use the iio_simple_dummy_write_event_config() function to
actually enable and disable the IRQ.

And it would be good to understand why the interrupt was already
triggered.


> [   99.080761]  ? iio_sw_device_create+0x137/0x230
> [   99.081447]  ? __pfx_device_make_group+0x10/0x10
> [   99.082234]  ? device_make_group+0x33/0x80
> [   99.083106]  ? configfs_mkdir+0x449/0xdf0
> [   99.083836]  ? vfs_mkdir+0x452/0x760
> [   99.084457]  ? do_mkdirat+0x17b/0x330
> [   99.085022]  ? __pfx_do_mkdirat+0x10/0x10
> [   99.085543]  ? strncpy_from_user+0x129/0x210
> [   99.085998]  ? __x64_sys_mkdir+0xe6/0x130
> [   99.086506]  ? do_syscall_64+0x9e/0x1a0
> [   99.087118]  ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
> [   99.087936]  </TASK>
> [   99.088323] Modules linked in: iio_dummy iio_dummy_evgen
> [   99.088949] ---[ end trace 0000000000000000 ]---
> [   99.089526] RIP: 0010:__x86_indirect_thunk_r13+0xa/0x20
> [   99.090194] Code: e8 01 00 00 00 cc 4c 89 24 24 c3 cc cc cc cc 90
> 66 66 2e 0f 1f 84 00 00 00 00 00 0f 0
> [   99.093617] RSP: 0018:ffff8880035a7bd0 EFLAGS: 00010246
> [   99.094379] RAX: dffffc0000000000 RBX: ffff888008687828 RCX: 1ffff11000725946
> [   99.095596] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888008686000
> [   99.097176] RBP: ffff88800392ca00 R08: 0000000000000001 R09: ffffed10006b4f78
> [   99.098109] R10: ffff8880035a7bc7 R11: ffffffff8ca58570 R12: 0000000000000000
> [   99.098893] R13: 65645f7974743a72 R14: ffffffff8c5e5420 R15: ffff888008687870
> [   99.101368] FS:  00007fe43adc2400(0000) GS:ffff88806d300000(0000)
> knlGS:0000000000000000
> [   99.102606] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   99.105567] CR2: 000056088dfb66c0 CR3: 0000000001fc2000 CR4: 00000000000006f0
> [   99.107410] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   99.108835] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Segmentation fault
> 
> Any help or guidance would be appreciated
> 
> I'm planning to apply for GSOC but I think it's already late. Should I
> try writing a proposal?

It looks like there are still a few days left before the deadline.

If you haven't seen the other recent discussions, you will probably find some
useful info here: https://lore.kernel.org/linux-iio/?q=gsoc

> 
> Thank you,
> Waseem
>