Bug#1120602: hyper-v: BUG: kernel NULL pointer dereference, address: 00000000000000a0
Control: tags -1 + upstream
Control: tags -1 - moreinfo
Hi Peter,
On Thu, Nov 13, 2025 at 01:14:37PM +0000, Peter Morrow wrote:
> Hi Salvatore,
>
> Thank you for your reply and maintainership!
Welcome :)
> 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.
Thanks for doing so.
> >
> > 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.
Ok that is already a good result thank you. The next step is to
forward it upstream, will do shortly, still the following point:
> >
> > 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.
Not necessarily if it is a problem for deploying it for your
enviornment. If you can, then we have the benefit to confirm to
upstream that indeed it is still affecting more recent versions, and
unlikely that some other changes inbetween make the issue disapear
(even if there is no commit with fixes tag to the orginal commit).
So not necessary, but still helpful to confirm that even newer
branches are affected.
I will preapre the report upstream, and upstream might have questions
back to you.
Regards,
Salvatore
Reply to: