Bug#1118437: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space

[Jason Xing <kerneljasonxing@gmail.com>]

On Tue, Oct 21, 2025 at 8:59 PM mc36 <csmate@nop.hu> wrote:
>
> hi,
>
> you both are crazy good, thank you so much for both of your effort! :)
>
>
> if you're in a need for some more complicated xsk tests, just let me know, freertr
>
> have a dataplane and a socat-alike tool with an xsk based packetio for a while....

Could you provide a link that points to what you just mentioned? I
believe more tests on veth are necessary.

Thanks,
Jason

>
> br,
>
> cs
>
> On 10/21/25 14:25, Jason Xing wrote:
> > On Tue, Oct 21, 2025 at 6:52   PM Fernando Fernandez Mancera
> > <fmancera@suse.de> wrote:
> >>
> >>
> >>
> >> On 10/20/25 11:31 PM, mc36 wrote:
> >>> hi,
> >>>
> >>> On 10/20/25 11:04, Jason Xing wrote:
> >>>>
> >>>> I followed your steps you attached in your code:
> >>>> ////// gcc xskInt.c -lxdp
> >>>> ////// sudo ip link add veth1 type veth
> >>>> ////// sudo ip link set veth0 up
> >>>> ////// sudo ip link set veth1 up
> >>>
> >>> ip link set dev veth1 address 3a:10:5c:53:b3:5c
> >>>
> >>>> ////// sudo ./a.out
> >>>>
> >>> that will do the trick on a recent kerlek....
> >>>
> >>> its the destination mac in the c code....
> >>>
> >>> ps: chaining in the original reporter from the fedora land.....
> >>>
> >>>
> >>> have a nice day,
> >>>
> >>> cs
> >>>
> >>>
> >>
> >> hi, FWIW I have reproduced this and I bisected it, issue was introduced
> >> at 30f241fcf52aaaef7ac16e66530faa11be78a865 - working on a patch.
> >
> > Exactly. I simply reverted it and its dependencies and didn't see any
> > crash then. It was newly introduced, hopefully it will not bring much
> > trouble. As I replied before, I will take a look tomorrow morning.
> >
> > Thanks,
> > Jason
>