lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iKjJ-P0YR-oGzEd+EvrFAQA=0LsjsYHUDpFNRHCDwXeWA@mail.gmail.com>
Date: Wed, 17 Dec 2025 16:22:28 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: ALOK TIWARI <alok.a.tiwari@...cle.com>
Cc: Aditya Gupta <adityag@...ux.ibm.com>, linux-kernel@...r.kernel.org, 
	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [External] : Re: [REPORT] Null pointer deref in net/core/dev.c on PowerPC

On Wed, Dec 17, 2025 at 4:02 PM ALOK TIWARI <alok.a.tiwari@...cle.com> wrote:
>
>
>
> On 12/17/2025 8:11 PM, Eric Dumazet wrote:
> > On Wed, Dec 17, 2025 at 2:58 PM Eric Dumazet <edumazet@...gle.com> wrote:
> >>
> >> On Wed, Dec 17, 2025 at 2:49 PM Eric Dumazet <edumazet@...gle.com> wrote:
> >>>
> >>> On Wed, Dec 17, 2025 at 1:10 PM Aditya Gupta <adityag@...ux.ibm.com> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> I see a null pointer dereference in 'net/core/dev.c', with 6.19.0-rc1,
> >>>> when using e1000e device in qemu.
> >>>>
> >>>> I am able to reproduce the issue on PowerNV and PSeries machines on Power
> >>>> architecture, though this might be possible on other architectures also.
> >>>>
> >>>> Console log
> >>>> -----------
> >>>>
> >>>>          ...
> >>>>          Starting network: udhcpc: started, v1.35.0
> >>>>          udhcpc: broadcasting discover
> >>>>          [    6.389648] Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
> >>>>          [    6.394166] BUG: Kernel NULL pointer dereference on read at 0x00000000
> >>>>          [    6.394262] Faulting instruction address: 0xc00000000166e080
> >>>>          [    6.395253] Oops: Kernel access of bad area, sig: 11 [#1]
> >>>>          [    6.398372] LE PAGE_SIZE=64K MMU=Radix  SMP NR_CPUS=2048 NUMA pSeries
> >>>>          [    6.398647] Modules linked in:
> >>>>          [    6.399553] CPU: 0 UID: 0 PID: 203 Comm: udhcpc Not tainted 6.19.0-rc1+ #3 PREEMPT(voluntary)
> >>>>          [    6.399757] Hardware name: IBM pSeries (emulated by qemu) POWER9 (architected) 0x4e1202 0xf000005 of:SLOF,git-6b6c16 pSeries
> >>>>          [    6.400002] NIP:  c00000000166e080 LR: c00000000166e080 CTR: 0000000000000000
> >>>>          [    6.400148] REGS: c00000000c67b4f0 TRAP: 0300   Not tainted  (6.19.0-rc1+)
> >>>>          [    6.400275] MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 44022860  XER: 20040147
> >>>>          [    6.400544] CFAR: c00000000165ef0c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
> >>>>          [    6.400544] GPR00: c00000000166e080 c00000000c67b790 c0000000028ca300 0000000000000002
> >>>>          [    6.400544] GPR04: c00000000324a568 000000000001a560 0000000000000020 0000000000000000
> >>>>          [    6.400544] GPR08: 0000000000000000 0000000000000000 0000000000000201 0000000028022862
> >>>>          [    6.400544] GPR12: 0000000000000001 c0000000041a0000 0000000000000000 0000000000000000
> >>>>          [    6.400544] GPR16: 0000000000000000 0000000000000010 0000000000000148 0000000000000148
> >>>>          [    6.400544] GPR20: 0000000000000000 0000000000000008 00000000000005dc c000000003ea5e98
> >>>>          [    6.400544] GPR24: c000000003ea5e94 0000000000000000 c000000005b7e200 0000000000000001
> >>>>          [    6.400544] GPR28: 0000000000000000 0000000000000000 0000000000000000 c000000003ea5d80
> >>>>          [    6.401178] NIP [c00000000166e080] __dev_xmit_skb+0x484/0xb88
> >>>>          [    6.401697] LR [c00000000166e080] __dev_xmit_skb+0x484/0xb88
> >>>>          [    6.401843] Call Trace:
> >>>>          [    6.401938] [c00000000c67b790] [c00000000166e080] __dev_xmit_skb+0x484/0xb88 (unreliable)
> >>>>          [    6.402060] [c00000000c67b810] [c0000000016738a4] __dev_queue_xmit+0x4b4/0xa94
> >>>>          [    6.402122] [c00000000c67b970] [c00000000192748c] packet_xmit+0x10c/0x1b0
> >>>>          [    6.402190] [c00000000c67b9f0] [c00000000192af6c] packet_snd+0x784/0xa04
> >>>>          [    6.402278] [c00000000c67bad0] [c00000000162a91c] __sys_sendto+0x1dc/0x250
> >>>>          [    6.402340] [c00000000c67bc20] [c00000000162a9c4] sys_sendto+0x34/0x44
> >>>>          [    6.402400] [c00000000c67bc40] [c000000000031870] system_call_exception+0x170/0x360
> >>>>          [    6.402468] [c00000000c67be50] [c00000000000cedc] system_call_vectored_common+0x15c/0x2ec
> >>>>          ...
> >>>>
> >>>> Git Blame
> >>>> ---------
> >>>>
> >>>> Debugging with GDB points to this code in 'net/core/dev.c':
> >>>>
> >>>>          static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
> >>>>                                           struct net_device *dev,
> >>>>                                           struct netdev_queue *txq)
> >>>>          {
> >>>>          ...
> >>>>                          llist_for_each_entry_safe(skb, next, ll_list, ll_node) {
> >>>>                                  prefetch(next);
> >>>>                                  prefetch(&next->priority);                                              <----------
> >>>>                                  skb_mark_not_on_list(skb);
> >>>>                                  rc = dev_qdisc_enqueue(skb, q, &to_free, txq);
> >>>>                                  count++;
> >>>>                          }
> >>>>
> >>>> Git blame points to this commit which introduced the use of 'next->priority':
> >>>>
> >>>>          commit b2e9821cff6c3c9ac107fce5327070f4462bf8a7
> >>>>          Date:   Fri Nov 21 08:32:52 2025 +0000
> >>>>
> >>>>              net: prefech skb->priority in __dev_xmit_skb()
> >>>>
> >>>> Reproducing the issue
> >>>> ---------------------
> >>>>
> >>>> To reproduce the issue:
> >>>> 1. Attaching config as attachment
> >>>> 2. Kernel commit I built: 'commit 40fbbd64bba6 ("Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs")'
> >>>> 3. Initramfs (it's buildroot): https://urldefense.com/v3/__https://ibm.box.com/s/x70ducx9cxl9tz4abh97d9b508ildync__;!!ACWV5N9M2RV99hQ!JFK4bRaMJqtwI1HPrt0RUtQ-Ti5RfIOMf_XvhccLjHCtWhOgpn4WF1qglGxo1Z0nXM_TcGB7PehRPosqE_4L$
> >>>> 4. QEMU command line: 'qemu-system-ppc64 -M pseries -m 10G -kernel ~/some-path/zImage -append "init=/bin/sh noreboot debug" -nographic -initrd ~/some-path/rootfs-with-ssh.cpio -netdev user,id=net0 -device e1000e,netdev=net0
> >>>>
> >>>> Thanks,
> >>>> - Aditya G
> >>>>
> >>>
> >>> This seems to be a platform issue.
> >>>
> >>> prefetch(NULL) (or prefetch (amount < PAGE_SIZE)) is not supposed to fault.
> >>
> >> Special casing of NULL was added in :
> >>
> >> commit e63f8f439de010b6227c0c9c6f56e2c44dbe5dae
> >> Author: Olof Johansson <olof@...tin.ibm.com>
> >> Date:   Sat Apr 16 15:24:38 2005 -0700
> >>
> >>      [PATCH] ppc64: no prefetch for NULL pointers
> >
> > I will send the following fix, thanks.
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 9094c0fb8c68..36dc5199037e 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -4241,9 +4241,11 @@ static inline int __dev_xmit_skb(struct sk_buff
> > *skb, struct Qdisc *q,
> >                  int count = 0;
> >
> >                  llist_for_each_entry_safe(skb, next, ll_list, ll_node) {
> > -                       prefetch(next);
> > -                       prefetch(&next->priority);
> > -                       skb_mark_not_on_list(skb);
> > +                       if (next) {
> > +                               prefetch(next);
> > +                               prefetch(&next->priority);
> > +                               skb_mark_not_on_list(skb);
> > +                       }
> >                          rc = dev_qdisc_enqueue(skb, q, &to_free, txq);
> >                          count++;
> >                  }
> >
>
> why not only ?
> if (likely(next)) {
>      prefetch(next);
>      prefetch(&next->priority);
> }

Because we also can avoid clearing skb->next, we know it is already NULL.

Since we pay the price of a conditional, let's amortize its cost :/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ