Bug#1120602: hyper-v: BUG: kernel NULL pointer dereference, address: 00000000000000a0
+ bug-tracking alias.
On Thu, 13 Nov 2025 at 13:14, Peter Morrow <pdmorrow@gmail.com> wrote:
>
> Hi Salvatore,
>
> Thank you for your reply and maintainership!
>
> On Thu, 13 Nov 2025 at 06:20, Salvatore Bonaccorso <carnil@debian.org> wrote:
> >
> > Control: tags -1 + moreinfo
> >
> > Hi Peter,
> >
> > Thanks a lot for the report.
> >
> > On Wed, Nov 12, 2025 at 10:56:38PM +0000, Peter Morrow wrote:
> > > Package: src:linux
> > > Version: 6.12.57-1
> > > Severity: important
> > > X-Debbugs-Cc: pdmorrow@gmail.com
> > >
> > > Dear Maintainer,
> > >
> > > I'm seeing a kernel crash quite soon after boot on a debian trixie based
> > > system running 6.12.57+deb13-amd64, unfortunately the kernel panics before
> > > I can access the system to gather more information. Thus I'll provide details
> > > of the system using a previously known good version. The panic is happening
> > > 100% of the time unfortunately. I have access to the serial console however
> > > so can enable any required verbose logging during boot if necessary.
> > >
> > > Crucially the crash is not seen with kernel version 6.12.41+deb13-amd64 with the
> > > same userspace. We had pinned to that version until very recently to in order
> > > to work around https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109676
> > >
> > > I'm running a dpdk application here (VPP) on Azure, VM form factor is a
> > > "Standard DS3 v2 (4 vcpus, 14 GiB memory)".
> > >
> > > The only relevant upstream commit in this area (as far as I can see) is:
> > >
> > > https://lore.kernel.org/linux-hyperv/1bb599ee-fe28-409d-b430-2fc086268936@linux.microsoft.com/
> > >
> > > The comment regarding avoiding races at start adds a bit more weight behind this
> > > hunch, though it's only a hunch as I am most definitely nowhere near an expert
> > > in this area.
> >
> > I have a couple of questions. As you pinned 6.12.41+deb13-amd64, but
> > this was not the most recent kernel for trixie, can you confirm you
> > are seeing or not seeing the issue as well with 6.12.48-1 (this was
> > released via security update).
>
> I installed linux-image-6.12.48+deb13-amd64 and can confirm it's working fine,
> no crashes on boot.
>
> >
> > This would help narrowing the range further.
> >
> > The commit b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of
> > interrupt mask") was backported to 6.12.53, so if you do not see the
> > problem with 6.12.48-1 then this further weight for the offending
> > commit.
> >
> > Secondly: Would you have either the possibility to bisect the changes
> > between the given range of good/bad kernel to isolate the offending
> > commit with a proof? Alternatively could you build 6.12.57-1 with the
> > commit reverted only? (you can use the debian/bin/test-patches script
> > for that, instructions in
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4,
> > let me know though if you need help to make the patch to be used).
>
> I was able to build 6.12.57-1 with b15b7d2a1b09 reverted using test-patches and
> confirm that the kernel does not panic on boot. So it looks fairly
> conclusive to me that
> b15b7d2a1b09 is the culprit for me.
>
> >
> > Could you additionally (just to test, then revert back to the regular
> > trixie kernel series) test the 6.17.7-2 kernel from unstable? This one
> > would include as well a backport of b15b7d2a1b09.
>
> Would you still like this test done? I suspect it's not required now with the
> data we have on b15b7d2a1b09.
>
> Thanks,
> Peter.
>
> >
> > Regards,
> > Salvatore
Reply to: