On 31.01.24 11:48, Mike Rapoport wrote:
On Wed, Jan 31, 2024 at 10:15:11AM +0100, David Hildenbrand wrote:
On 31.01.24 03:01, Pengfei Xu wrote:
Hi Mike,
Greeting!
There is "unable to handle kernel paging request in fuse_copy_one" BUG in
intel-6.8-rc2:
All detailed info: https://github.com/xupengfe/syzkaller_logs/tree/main/240130_184751_fuse_copy_one
Syzkaller reproduced code: https://github.com/xupengfe/syzkaller_logs/blob/main/240130_184751_fuse_copy_one/repro.c
Syzkaller repro syscall steps: https://github.com/xupengfe/syzkaller_logs/blob/main/240130_184751_fuse_copy_one/repro.prog
Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/240130_184751_fuse_copy_one/bisect_info.log
Issue dmesg: https://github.com/xupengfe/syzkaller_logs/blob/main/240130_184751_fuse_copy_one/41bccc98fb7931d63d03f326a746ac4d429c1dd3_dmesg.log
bzImage: https://github.com/xupengfe/syzkaller_logs/raw/main/240130_184751_fuse_copy_one/bzImage_v6.8-rc2.tar.gz
Kconfig(make olddefconfig): https://github.com/xupengfe/syzkaller_logs/blob/main/240130_184751_fuse_copy_one/kconfig_origin
Bisected and found first bad commit is:
b758fe6df50da mm/secretmem: make it on by default
Sounds like we manage to access a page that has its direct map removed --
either because it's actual secretmem memory, or because we fail to restore
the direct map.
Judging by the repro code and the registers, it's an access to secretmem.
The call
syscall(__NR_write, /*fd=*/r[0], /*arg=*/0x20000040ul, /*len=*/0x50ul);
will eventually get to
memcpy(0xffff88800e2afa80, 0xffff8880119a5040, 0x0000000000000010)
and I think that 0x20000040 in repro address space maps to
0xffff8880119a5040 in the direct map.
So it looks like secretmem actually works :)
Good. How can we prevent triggering BUGs? The write system call should
fail gracefully (and I thought it would).
--
Cheers,
David / dhildenb
