Re: [syzbot] [kernel?] general protection fault in psi_task_change

[Shuai Liu]

Hi,

I had a look at this report. The fault is not a bug in psi/cgroup; it is
the reproducer reconfiguring the Q35 host bridge so that an ECAM window
overlaps DRAM. Please consider marking the bug invalid.

What the crash actually dereferences
------------------------------------
cgroup_ino() is reached with cset->dfl_cgrp == 0xffffffffffffffff. The
register dump confirms the load path:

  mov 0x88(%r13),%r15   ; r13 = task->cgroups = ffff888054570000
                        ; dfl_cgrp is at offset 0x88, i.e.
                        ; CGROUP_SUBSYS_COUNT == 15
                        ; (CONFIG_CGROUP_DEBUG=y, CONFIG_CGROUP_DMEM=n)
  lea 0x1a0(%r15),%rdi  ; &cgrp->kn, -1 + 0x1a0 = 0x19f
  shr $0x3,%rdx
  cmpb $0x0,(%rdx,%rax,1)   ; KASAN shadow check, faults here

The load of [r13+0x88] itself passed the KASAN check, so the css_set is
alive and initialized; only those eight bytes read back as all-ones.
dfl_cgrp is a valid cgroup pointer by construction and is never -1, and
neither a use-after-free nor a migration race explains this: both would
have failed the shadow check first, or left a sane stale pointer behind.

Where the all-ones come from
----------------------------
The reproducer does:

  openat("./proc/bus/pci/00/00.0", O_RDWR);   /* Q35 host bridge */
  write(fd, "R-", 2)   x64, async
  write(fd, "-1\0", 3) x64, async

Both writes are async and share one file description, so the 2-byte and
3-byte chunks interleave while the file position advances. That sprays an
arbitrary mix of the bytes {0x52, 0x2d, 0x31, 0x00} over offsets
0x00-0x13f of the host bridge config space (clamped to cfg_size).

Offset 0x60 is PCIEXBAR. Those four byte values are enough to program

  enable = 1                  (bit 0, from 0x2d or 0x31)
  length = 64 MiB or more     (bits 2:1)
  base   = 0x52000000         (byte 3 = 0x52, byte 2 = 0x00)

so the ECAM window [0x52000000, 0x52000000 + length) is placed over DRAM.
The crashed css_set sits at

  0xffff888054570000 - 0xffff888000000000 = 0x54570000

which is inside that window. Accesses there no longer reach DRAM; they are
decoded as PCI config space, and an address that does not decode to a
device returns all-ones. The KASAN shadow lives at a different physical
address, which is exactly why the object still looks valid and the fault
is deferred to the next dereference.

Corroborating observations
--------------------------
* At the same timestamp another CPU reported an unrelated

    BUG: kernel NULL pointer dereference, address: 0x0000000000000f

  Two independent faults in unrelated subsystems at the same instant is
  the signature of a changed memory map, not of a cgroup race.

* proc_bus_pci_write() is not itself broken: drivers/pci/proc.c clamps
  nbytes to dev->cfg_size (pos >= size, pos + nbytes > size), so there is
  no out-of-bounds access on the kernel side. The write reaches the
  emulated host bridge and reprograms it, which is what root is allowed
  to do.

So there is no kernel change that fixes this crash. Preventing it would
require lockdown (proc_bus_pci_write() already fails with -EPERM for
LOCKDOWN_PCI_ACCESS), or dropping the /proc/bus/pci writes from the
reproducer.

#syz invalid

Thanks,
Shuai Liu