Bug#1120602: hyper-v: BUG: kernel NULL pointer dereference, address: 00000000000000a0
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).
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).
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.
Regards,
Salvatore
Reply to: