Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on

[Mark Rutland]

On Thu, Jul 17, 2025 at 11:25:00AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > -----邮件原件-----
> > 发件人: Mark Rutland <mark.rutland at arm.com>

> > From a quick scan, I think this might have something to do with UNWIND_PATCH_PAC_INTO_SCS, notes below.
> > 
> > On Mon, Jul 14, 2025 at 03:12:33AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > > I am enabling generic kasan feature in kernel 6.12, and met kernel boot crash.
> > > Unable to handle kernel NULL pointer dereference at virtual address
> > > 0000000000000008 pc : do_basic_setup+0x6c/0xac lr :
> > > do_basic_setup+0x88/0xac sp : ffffffc080087e40

> > Here you evidently have shadow call stack enabled...
> > 
> > > NSX:FFFFFFC0800A8478|D503233F  asan.module_ctor:    paciasp
> > > NSX:FFFFFFC0800A847C|A9BF7BFD                       stp     x29,x30,[sp,#-0x10]!   ; x29,x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A8480|910003FD                       mov     x29,sp
> > > NSX:FFFFFFC0800A8484|B0023420                       adrp    x0,0xFFFFFFC08472D000
> > > NSX:FFFFFFC0800A8488|913E0000                       add     x0,x0,#0xF80     ; x0,x0,#3968
> > > NSX:FFFFFFC0800A848C|52800021                       mov     w1,#0x1          ; w1,#1
> > > NSX:FFFFFFC0800A8490|9422AF35                       bl      0xFFFFFFC080954164   ; __asan_register_globals
> > > NSX:FFFFFFC0800A8494|A8C17BFD                       ldp     x29,x30,[sp],#0x10   ; x29,x30,[sp],#16
> > > NSX:FFFFFFC0800A8498|D50323BF                       autiasp
> > > NSX:FFFFFFC0800A849C|D65F03C0                       ret
> > 
> > ... but here you evidently don't, and have PAC instead.

> > Are these decoded from the static kernel binary, or are these dumps
> > from memory once a kernel has booted (or is in the process of
> > booting)?
> 
>  These are dumped from memory during the kernel booted by trace32.

At which point have you dumped the memory contents? e.g. has the kernel
booted to a prompt before you make the dump, or have you stopped the
kernel early during the boot process?

Are you certain this is dumped *after* scs_patch() has run?

> > > But actually, in two asan.module_ctor functions, there is only autiasp  instruction inserted before return, for validation of return address,
> > while paciasp instruction is missing before.
> > > NSX:FFFFFFC0800A72D8|F800865E  asan.module_ctor:    str     x30,[x18],#0x8   ; x30,[x18],#8
> > > NSX:FFFFFFC0800A72DC|F81F0FFE                       str     x30,[sp,#-0x10]!   ; x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A72E0|B00233C0                       adrp    x0,0xFFFFFFC084720000
> > > NSX:FFFFFFC0800A72E4|91350000                       add     x0,x0,#0xD40     ; x0,x0,#3392
> > > NSX:FFFFFFC0800A72E8|52803D61                       mov     w1,#0x1EB        ; w1,#491
> > > NSX:FFFFFFC0800A72EC|9422B39E                       bl      0xFFFFFFC080954164   ; __asan_register_globals
> > > NSX:FFFFFFC0800A72F0|F84107FE                       ldr     x30,[sp],#0x10   ; x30,[sp],#16
> > > NSX:FFFFFFC0800A72F4|D50323BF                       autiasp
> > > NSX:FFFFFFC0800A72F8|D65F03C0                       ret
> > 
> > Thas has a mixture of SCS and PAC; there's a shadow call stack prologue but a PAC epilogue:
> > 
> >         str     x30, [x18], #8  // SCS
> >         ...
> >         autiasp                 // PAC
> 
> Yes, this is my issue and I wanted to resolve.
> 
> > ... so I'll hazard a guess that these are dumps from memory, 

This was confirmed above...

> > and you have UNWIND_PATCH_PAC_INTO_SCS selected.

... can you please confirm this? i.e. does your config have
CONFIG_UNWIND_PATCH_PAC_INTO_SCS selected?

> > Assuming that is the case, either this dump has been made
> > mid-patching, or the patching has gone wrong somehow and left the
> > prologues/epilogues in an inconsistent state (and the NULL
> > dereference could be a secondary effect of that).
> >
> > Ard, does that sound plausible to you?
> >
> > I can't see why that would depend on KBUILD_RUSTFLAGS, but maybe the DWARF generated by rustc has confused the patching code
> > somehow, or the linker has aggregated that in a suprising way.
> > Mark.
> 
>   Yes, Thank you. What can cause this issue? Can you give some
>   directions so that we can gradually investigate.

Find out specifically where the affected asan.module_ctor functions are
from, i.e. whether they're generated by rustc or the C compiler that
you're using.

Go and read scs_patch(), see what it does, and check the data it
consumes.

See if rustc is generating DWARF as we expect or not.

See if the linker is combining that correctly into the resulting
vmlinux, and that this correctly propagates into the resulting Image.

Mark.