[syzbot] [iommu?] kernel BUG in dma_alloc_attrs

[syzbot] [iommu?] kernel BUG in dma_alloc_attrs

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    1d227fcc7222 Merge tag 'net-6.12-rc3' of git://git.kernel...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12c56f07980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=7cd9e7e4a8a0a15b
dashboard link: https://syzkaller.appspot.com/bug?extid=b4bfacdec173efaa8567
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=14572840580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12572840580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-1d227fcc.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ea82465646ea/vmlinux-1d227fcc.xz
kernel image: https://storage.googleapis.com/syzbot-assets/f764dd6d008a/bzImage-1d227fcc.xz

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

------------[ cut here ]------------
kernel BUG at arch/x86/mm/physaddr.c:28!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5114 Comm: syz-executor411 Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #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:__phys_addr+0x162/0x170 arch/x86/mm/physaddr.c:28
Code: e8 23 e8 51 00 48 c7 c7 c0 86 7a 8e 4c 89 f6 4c 89 fa e8 f1 98 b1 03 e9 45 ff ff ff e8 07 e8 51 00 90 0f 0b e8 ff e7 51 00 90 <0f> 0b e8 f7 e7 51 00 90 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90002d4f4c0 EFLAGS: 00010293
RAX: ffffffff8142ff51 RBX: 0000000000000001 RCX: ffff88800023a440
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc90002d4f5e8 R08: ffffffff8142fe9c R09: 312e64313a30303a
R10: dffffc0000000000 R11: fffff91ffff86755 R12: ffffe8ffffc33a60
R13: dffffc0000000000 R14: 000040800b111000 R15: 000000000000002e
FS:  0000555576947380(0000) GS:ffff88801fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffabc3020f0 CR3: 000000004020a000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 virt_to_phys arch/x86/include/asm/io.h:131 [inline]
 perf_trace_dma_alloc+0x3dd/0x620 include/trace/events/dma.h:117
 trace_dma_alloc include/trace/events/dma.h:117 [inline]
 dma_alloc_attrs+0x46c/0x4e0 kernel/dma/mapping.c:622
 usbdev_mmap+0x247/0x900 drivers/usb/core/devio.c:251
 call_mmap include/linux/fs.h:2172 [inline]
 mmap_region+0x1add/0x2990 mm/mmap.c:1440
 do_mmap+0x8f0/0x1000 mm/mmap.c:496
 vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:588
 ksys_mmap_pgoff+0x4eb/0x720 mm/mmap.c:542
 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:0x7ffabc28b979
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 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:00007ffd4658b118 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffabc28b979
RDX: 0000000001000002 RSI: 0000000000400000 RDI: 0000000020000000
RBP: 00007ffabc2fe5f0 R08: 0000000000000004 R09: 0000000000000000
R10: 0000000000011012 R11: 0000000000000246 R12: 0000000000000001
R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__phys_addr+0x162/0x170 arch/x86/mm/physaddr.c:28
Code: e8 23 e8 51 00 48 c7 c7 c0 86 7a 8e 4c 89 f6 4c 89 fa e8 f1 98 b1 03 e9 45 ff ff ff e8 07 e8 51 00 90 0f 0b e8 ff e7 51 00 90 <0f> 0b e8 f7 e7 51 00 90 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90002d4f4c0 EFLAGS: 00010293
RAX: ffffffff8142ff51 RBX: 0000000000000001 RCX: ffff88800023a440
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc90002d4f5e8 R08: ffffffff8142fe9c R09: 312e64313a30303a
R10: dffffc0000000000 R11: fffff91ffff86755 R12: ffffe8ffffc33a60
R13: dffffc0000000000 R14: 000040800b111000 R15: 000000000000002e
FS:  0000555576947380(0000) GS:ffff88801fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffabc3020f0 CR3: 000000004020a000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
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

Re: [syzbot] [iommu?] kernel BUG in dma_alloc_attrs

[Christoph Hellwig]

The problem is that the dma alloc/free tracing calls virt_to_phys
on the allocated/free memory.  But that memory can be vmalloced as
in this case.  I think we don't have weirdo allocators or pools any
more that are neither in the direct kernel mapping or vmalloc, so
we might be able to do an

		if (is_vmalloc_addr())
			page_to_phys(vmalloc_to_page()))
		else
			virt_to_page()

here.  Or just switch to tracing the virtual address to always be
on the safe side.

Re: [syzbot] [iommu?] kernel BUG in dma_alloc_attrs

[Sean Anderson]

On 10/16/24 04:02, Christoph Hellwig wrote:
> The problem is that the dma alloc/free tracing calls virt_to_phys
> on the allocated/free memory.  But that memory can be vmalloced as
> in this case.  I think we don't have weirdo allocators or pools any
> more that are neither in the direct kernel mapping or vmalloc, so
> we might be able to do an
> 
> 		if (is_vmalloc_addr())
> 			page_to_phys(vmalloc_to_page()))

Do we need offset_in_page?

> 		else
> 			virt_to_page()
> 
> here.  Or just switch to tracing the virtual address to always be
> on the safe side.
> 

Since this function returns a virtual address, I think that would be
fine.

--Sean

Re: [syzbot] [iommu?] kernel BUG in dma_alloc_attrs

[Christoph Hellwig]

On Thu, Oct 17, 2024 at 10:31:40AM -0400, Sean Anderson wrote:
> On 10/16/24 04:02, Christoph Hellwig wrote:
> > The problem is that the dma alloc/free tracing calls virt_to_phys
> > on the allocated/free memory.  But that memory can be vmalloced as
> > in this case.  I think we don't have weirdo allocators or pools any
> > more that are neither in the direct kernel mapping or vmalloc, so
> > we might be able to do an
> > 
> > 		if (is_vmalloc_addr())
> > 			page_to_phys(vmalloc_to_page()))
> 
> Do we need offset_in_page?

The DMA allocator always returns page aligned memory.

> Since this function returns a virtual address, I think that would be
> fine.

Ok, I'll look into that.  I'll need to check if %p gets obsfucated
for traces like it does for normal dmesg first, though.

Re: [syzbot] [iommu?] kernel BUG in dma_alloc_attrs

[Sean Anderson]

On 10/17/24 10:40, Christoph Hellwig wrote:
> On Thu, Oct 17, 2024 at 10:31:40AM -0400, Sean Anderson wrote:
>> On 10/16/24 04:02, Christoph Hellwig wrote:
>> > The problem is that the dma alloc/free tracing calls virt_to_phys
>> > on the allocated/free memory.  But that memory can be vmalloced as
>> > in this case.  I think we don't have weirdo allocators or pools any
>> > more that are neither in the direct kernel mapping or vmalloc, so
>> > we might be able to do an
>> > 
>> > 		if (is_vmalloc_addr())
>> > 			page_to_phys(vmalloc_to_page()))
>> 
>> Do we need offset_in_page?
> 
> The DMA allocator always returns page aligned memory.
> 
>> Since this function returns a virtual address, I think that would be
>> fine.
> 
> Ok, I'll look into that.  I'll need to check if %p gets obsfucated
> for traces like it does for normal dmesg first, though.
> 

I have a patch written up for this; will send it after testing.

--Sean