From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f54.google.com (mail-yx1-f54.google.com [74.125.224.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4857033C538 for ; Wed, 17 Dec 2025 15:22:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765984964; cv=none; b=HAvhFIGjzjOO92RsHY/hgjHmlKdHTtXOTUByOQrsprltNaJt84Gn+ysyztJnkNb85SarnDYu6uaiUPfPCFzkp0E/tRca5vMHYcttfVpvgcfF3LhOOcDT1rOV6pgHlPVojgxYl90vA8DzhrwnvhLmm1zSCLUnGwD5q4dId1lg4pA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765984964; c=relaxed/simple; bh=TLbsF26CFnxxGnC4pPP1emIgw036GIae15uxDXmdTYo=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZIyAvibfgCPxKpFgi1lE8LbdLg76JWsnKoqgYvM31q+ySHI5QfQAkP0cZH5w4prcf9UlJumnPBJuDanw8uHVGSZQV1VGPRbTQjsRHnC7HzzULDl+8FlFD+x8qAwaH+FCOyzP3xqyw8DOk9aHnpYVnf9HvT9+df5rxaaoPQnzaKI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=jZyPssKG; arc=none smtp.client-ip=74.125.224.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jZyPssKG" Received: by mail-yx1-f54.google.com with SMTP id 956f58d0204a3-644795bf5feso5558752d50.2 for ; Wed, 17 Dec 2025 07:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1765984961; x=1766589761; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3AyNi5WS76W6Julk1XnJm44whvIfOVahT+07T5M8LTQ=; b=jZyPssKGAd3rdKFkhh9rdj4gCRwlqudZhrUeTbP6AtQ6xtVj7oo4TPEYjHahMJtXTE Ogg14M/0xd3P2R1K4feRzuc1tAL8X5Io/ItcFncJMp8KIaisgqJwrjTT6XhdpSQMn/f/ c2twwNXZbHl7KoriZorDP57vx/G1Rxz6L/xgy/Kke0CaDqDf+8iHd0Bf3lisTxcQw/ss dxwocBU3dDyVSvpxwUO+2gnEcQvptDgdsnjHpP9G4Ca8cWMxK//cEKfyTf3dUdP50UZZ 1iOIAB2hkX72l+sK/1Y9g5ihHAXLvDLYTjIv/6eMnux6ph7EosqtoeZGOlxhGRE+mm9Y Xo3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765984961; x=1766589761; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3AyNi5WS76W6Julk1XnJm44whvIfOVahT+07T5M8LTQ=; b=rSiBrawPFpsCxuLNXr9Jq1isxXnx7FK39edMxy6Zntg3c4fxot1JCgpCGsUOEyLQa6 +BTC1CNBOeoriAkVgPypNIoxNSiQugjmS9+iHqjFhY5zJVbog+hqFHIHT9JulT0+CLpe K1PtE4gb8sMca1fX20U2F+8HmYNTHBuoMcCZEk9RYS3BcN0bvD/OOLUAD8K8ZRjm5SwZ 09myoasXk0piLxzwkAWpqk7pT8l85Bz7ywGbjA3JRQJg0FOKnqatMmbZUHf1+lXeFzRJ iYr/5C+iU9qY6mZWxOc3n0lnQvHO+1PP1hkoOBEOq10BVoUFenjAtGUTHuShKDi27qdL rjXQ== X-Forwarded-Encrypted: i=1; AJvYcCU2tXyVxHle/B+CzVP9f6jrxnz0iG4WZR6iXN1ANic9Y09KqfUwIXc7cqtfmGkj34E+u6oxTFY3xSpbBoo=@vger.kernel.org X-Gm-Message-State: AOJu0YyME/InPMgE35j23H8WMppLs+6u9EdNBNFfhecXsvw/ezINCZh9 c3JTSHvodq6ubjigC/eM6c9qyRio6A9y9vrWxcOVZ5xyXMFcoqVb6q2o76h6pS3t+hWDZmmOveu 1OViR5ZY2OME8pX716eVzblavKdjuP44jV6hVuGpN6FHOIaGcc7SYUXiE X-Gm-Gg: AY/fxX7FQNC+NL52MjaPD9GrrNMwSDibR5i3w/n8fqgUb/VunYqDwwCRFm/1n0cuWKZ s2psknS8vf6Oa2M+Vba2fv0KI5DHn9MT+EMtVhh3QcuX+6gcA2ZlIpZzUxAOgy3/WNlTRxnBNIA xSn/QOBFdugw+HiCcnn+/TKLBo5LysqZYGb7KhGgQKawsQfXyO+reLgsA2HZs0PIWmnYtI/fOnO AIBwyFYYBUPc4N8JR3pHZvJkvsQUmf3t+e38hLVlKOuYyVKa9T0lILXP1W9+s6oICsoL+1I X-Google-Smtp-Source: AGHT+IG1VJ1rKQiCMpO7CwLl1udwmZgJrqb5TjQFgqksBny46RqdqKwyAn1/ocRq6qT/j0sSmi7Sk9sLtvM2vQsEFlY= X-Received: by 2002:a05:690e:6d9:b0:63f:95dd:b2c9 with SMTP id 956f58d0204a3-6455564e725mr10918524d50.58.1765984960800; Wed, 17 Dec 2025 07:22:40 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <6d508d6a-6d4f-4b78-96e0-65e5dfe4e8f0@oracle.com> In-Reply-To: <6d508d6a-6d4f-4b78-96e0-65e5dfe4e8f0@oracle.com> From: Eric Dumazet Date: Wed, 17 Dec 2025 16:22:28 +0100 X-Gm-Features: AQt7F2odo0i9BFFLF9CvXGW90VttH9ERQbfEKWsZGEaNw8XKWsxrUO1mzIGZTM0 Message-ID: Subject: Re: [External] : Re: [REPORT] Null pointer deref in net/core/dev.c on PowerPC To: ALOK TIWARI Cc: Aditya Gupta , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, "David S. Miller" , Jakub Kicinski , Paolo Abeni Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 17, 2025 at 4:02=E2=80=AFPM ALOK TIWARI wrote: > > > > On 12/17/2025 8:11 PM, Eric Dumazet wrote: > > On Wed, Dec 17, 2025 at 2:58=E2=80=AFPM Eric Dumazet wrote: > >> > >> On Wed, Dec 17, 2025 at 2:49=E2=80=AFPM Eric Dumazet wrote: > >>> > >>> On Wed, Dec 17, 2025 at 1:10=E2=80=AFPM Aditya Gupta wrote: > >>>> > >>>> Hello, > >>>> > >>>> I see a null pointer dereference in 'net/core/dev.c', with 6.19.0-rc= 1, > >>>> 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 a= lso. > >>>> > >>>> Console log > >>>> ----------- > >>>> > >>>> ... > >>>> Starting network: udhcpc: started, v1.35.0 > >>>> udhcpc: broadcasting discover > >>>> [ 6.389648] Kernel attempted to read user page (0) - exp= loit attempt? (uid: 0) > >>>> [ 6.394166] BUG: Kernel NULL pointer dereference on read= at 0x00000000 > >>>> [ 6.394262] Faulting instruction address: 0xc00000000166= e080 > >>>> [ 6.395253] Oops: Kernel access of bad area, sig: 11 [#1= ] > >>>> [ 6.398372] LE PAGE_SIZE=3D64K MMU=3DRadix SMP NR_CPUS= =3D2048 NUMA pSeries > >>>> [ 6.398647] Modules linked in: > >>>> [ 6.399553] CPU: 0 UID: 0 PID: 203 Comm: udhcpc Not tain= ted 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 tain= ted (6.19.0-rc1+) > >>>> [ 6.400275] MSR: 8000000000009033 CR: 44022860 XER: 20040147 > >>>> [ 6.400544] CFAR: c00000000165ef0c DAR: 0000000000000000= DSISR: 40000000 IRQMASK: 0 > >>>> [ 6.400544] GPR00: c00000000166e080 c00000000c67b790 c00= 00000028ca300 0000000000000002 > >>>> [ 6.400544] GPR04: c00000000324a568 000000000001a560 000= 0000000000020 0000000000000000 > >>>> [ 6.400544] GPR08: 0000000000000000 0000000000000000 000= 0000000000201 0000000028022862 > >>>> [ 6.400544] GPR12: 0000000000000001 c0000000041a0000 000= 0000000000000 0000000000000000 > >>>> [ 6.400544] GPR16: 0000000000000000 0000000000000010 000= 0000000000148 0000000000000148 > >>>> [ 6.400544] GPR20: 0000000000000000 0000000000000008 000= 00000000005dc c000000003ea5e98 > >>>> [ 6.400544] GPR24: c000000003ea5e94 0000000000000000 c00= 0000005b7e200 0000000000000001 > >>>> [ 6.400544] GPR28: 0000000000000000 0000000000000000 000= 0000000000000 c000000003ea5d80 > >>>> [ 6.401178] NIP [c00000000166e080] __dev_xmit_skb+0x484/= 0xb88 > >>>> [ 6.401697] LR [c00000000166e080] __dev_xmit_skb+0x484/0= xb88 > >>>> [ 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_se= ndto+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, struc= t Qdisc *q, > >>>> struct net_device *dev, > >>>> struct netdev_queue *txq) > >>>> { > >>>> ... > >>>> llist_for_each_entry_safe(skb, next, ll_lis= t, ll_node) { > >>>> prefetch(next); > >>>> prefetch(&next->priority); = <---------- > >>>> skb_mark_not_on_list(skb); > >>>> rc =3D dev_qdisc_enqueue(skb, q, &t= o_free, txq); > >>>> count++; > >>>> } > >>>> > >>>> Git blame points to this commit which introduced the use of 'next->p= riority': > >>>> > >>>> 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-fix= es' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs")' > >>>> 3. Initramfs (it's buildroot): https://urldefense.com/v3/__https://i= bm.box.com/s/x70ducx9cxl9tz4abh97d9b508ildync__;!!ACWV5N9M2RV99hQ!JFK4bRaMJ= qtwI1HPrt0RUtQ-Ti5RfIOMf_XvhccLjHCtWhOgpn4WF1qglGxo1Z0nXM_TcGB7PehRPosqE_4L= $ > >>>> 4. QEMU command line: 'qemu-system-ppc64 -M pseries -m 10G -kernel ~= /some-path/zImage -append "init=3D/bin/sh noreboot debug" -nographic -initr= d ~/some-path/rootfs-with-ssh.cpio -netdev user,id=3Dnet0 -device e1000e,ne= tdev=3Dnet0 > >>>> > >>>> 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 > >> 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 =3D 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 =3D 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 :/