| 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
| ||
|
Message-ID: <b0b17697-f23e-8fa5-3757-604a86f3a095@nvidia.com>
Date: Fri, 14 May 2021 15:24:58 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
linux-tegra <linux-tegra@...r.kernel.org>,
Thierry Reding <treding@...dia.com>
Subject: [BUG] net: stmmac: Panic observed in stmmac_napi_poll_rx()
Hello!
I have been looking into some random crashes that appear to stem from
the stmmac_napi_poll_rx() function. There are two different panics I
have observed which are ...
[ 19.591967] ------------[ cut here ]------------
[ 19.596701] kernel BUG at /home/jonathanh/kernel/include/linux/skbuff.h:2297!
[ 19.606273] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 19.611847] Modules linked in:
[ 19.615146] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.10.0 #1
[ 19.621357] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[ 19.628010] pstate: 00c00009 (nzcv daif +PAN +UAO -TCO BTYPE=--)
[ 19.634134] pc : eth_type_trans+0xf8/0x1a0
[ 19.638326] lr : stmmac_napi_poll_rx+0x340/0xbd0
[ 19.643123] sp : ffff800011f63ba0
[ 19.646544] x29: ffff800011f63ba0 x28: 00000000000005ea
[ 19.651995] x27: ffff0003d4fe48c0 x26: 00000000000000d3
[ 19.657532] x25: ffff0003d4fe48c0 x24: 0000000000000000
[ 19.662961] x23: ffff0000828d1a40 x22: ffff000083497f00
[ 19.668503] x21: ffff000084b4d6c0 x20: ffff800011b79000
[ 19.673934] x19: 0000000000000000 x18: 0000000000000000
[ 19.679472] x17: 0000000000000000 x16: ffff00008095e291
[ 19.684953] x15: 0000000000000001 x14: 4f77dff9f5ddb24a
[ 19.690425] x13: 3ecd4adcbed3184e x12: bca593c98536d7f5
[ 19.695860] x11: 62327b117d535683 x10: 69f6607bf62388d6
[ 19.701297] x9 : a65753eedd84defc x8 : ffff000084b4dcd0
[ 19.706836] x7 : ffff000084b4dcc0 x6 : 0000000000000000
[ 19.712271] x5 : 0000000000001000 x4 : 0000008000000000
[ 19.717810] x3 : 00000000ffffffea x2 : 00000000000005dc
[ 19.723241] x1 : ffff0003d4fe4000 x0 : ffff000083497f00
[ 19.728777] Call trace:
[ 19.731322] eth_type_trans+0xf8/0x1a0
[ 19.735163] stmmac_napi_poll_rx+0x340/0xbd0
[ 19.739540] net_rx_action+0x220/0x368
[ 19.743387] __do_softirq+0x10c/0x264
[ 19.747145] run_ksoftirqd+0x44/0x58
[ 19.750840] smpboot_thread_fn+0x1d0/0x298
[ 19.755025] kthread+0x120/0x150
[ 19.758484] ret_from_fork+0x10/0x1c
[ 19.762235] Code: 52800063 33000862 39020002 17ffffe0 (d4210000)
[ 19.768472] ---[ end trace 8e68a50b77108dd8 ]---
[ 19.773159] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt
[ 19.780636] SMP: stopping secondary CPUs
[ 19.785053] Kernel Offset: disabled
[ 19.788691] CPU features: 0x0240002,2300aa30
[ 19.793044] Memory Limit: none
[ 19.796183] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---
... or ...
[ 14.914607] Unable to handle kernel write to read-only memory at virtual address ffff000087ab3000
[ 14.924064] Mem abort info:
[ 14.927201] ESR = 0x9600014f
[ 14.930578] EC = 0x25: DABT (current EL), IL = 32 bits
[ 14.936484] SET = 0, FnV = 0
[ 14.939890] EA = 0, S1PTW = 0
[ 14.943603] Data abort info:
[ 14.946781] ISV = 0, ISS = 0x0000014f
[ 14.950995] CM = 1, WnR = 1
[ 14.954334] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000004505ae000
[ 14.961377] [ffff000087ab3000] pgd=000000047fff8003, p4d=000000047fff8003, pud=000000047fc6b003, pmd=000000047fc2d003, pte=0060000107ab3787
[ 14.974932] Internal error: Oops: 9600014f [#1] PREEMPT SMP
[ 14.980660] Modules linked in: tegra210_adma snd_hda_codec_hdmi snd_hda_tegra snd_hda_codec host1x snd_hda_core crct10dif_ce tegra_aconnect pwm_fan lm90 pwm_tegra tegra_bpmp_thermal phy_tegra194_p2u pcie_tegra194 at24 ip_tables x_tables ipv6
[ 15.003003] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.10.0 #1
[ 15.009381] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[ 15.016058] pstate: 80c00009 (Nzcv daif +PAN +UAO -TCO BTYPE=--)
[ 15.022364] pc : __dma_inv_area+0x40/0x58
[ 15.026660] lr : arch_sync_dma_for_cpu+0x1c/0x28
[ 15.031368] sp : ffff800011f63ba0
[ 15.035035] x29: ffff800011f63ba0 x28: 0000000000000000
[ 15.040658] x27: ffff0003d4fb88c0 x26: 00000000000000be
[ 15.046253] x25: ffff0003d4fb88c0 x24: 00000000000005ea
[ 15.051960] x23: ffff0000828bd7a0 x22: 00000000ffffffa8
[ 15.057544] x21: 0000000000000002 x20: ffff000080929010
[ 15.063251] x19: 0000000107a3d000 x18: 0000000000000001
[ 15.068957] x17: 0000000000000000 x16: 0000000000000000
[ 15.074517] x15: 0000000000000068 x14: b17d6301a8460a08
[ 15.080185] x13: 010100003bd8701b x12: 1080e9f16ff0a040
[ 15.086033] x11: 3bb9990301080263 x10: a8c00163a8c0ccd5
[ 15.091856] x9 : 06400040fb17dc05 x8 : ffff000083e108c0
[ 15.097401] x7 : ffff000083e108c0 x6 : 00000000ffffffa8
[ 15.102924] x5 : ffff8000109ca6e0 x4 : 0000000000000000
[ 15.108612] x3 : 000000000000003f x2 : 0000000000000040
[ 15.114302] x1 : ffff000187a3cf80 x0 : ffff000087ab3000
[ 15.119952] Call trace:
[ 15.122543] __dma_inv_area+0x40/0x58
[ 15.126521] dma_sync_single_for_cpu+0xac/0x100
[ 15.131195] stmmac_napi_poll_rx+0x490/0xbd0
[ 15.135786] net_rx_action+0x220/0x368
[ 15.139663] __do_softirq+0x10c/0x264
[ 15.143609] run_ksoftirqd+0x44/0x58
[ 15.147452] smpboot_thread_fn+0x1d0/0x298
[ 15.151678] kthread+0x120/0x150
[ 15.155042] ret_from_fork+0x10/0x1c
[ 15.158772] Code: 8a230000 54000060 d50b7e20 14000002 (d5087620)
[ 15.165228] ---[ end trace 23cff873d17a8509 ]---
This is seen on our Tegra194 Jetson AGX Xavier and it seems that it
is more likely to occur when the CPU is operating at slower
frequencies. For instance if I set the CPU speed to the min of
115.2MHz it occurs more often but not 100%.
Please note that although the above panics logs are from 5.10, it
is also seen with the current mainline.
The bug being triggered in skbuff.h is the following ...
void *skb_pull(struct sk_buff *skb, unsigned int len);
static inline void *__skb_pull(struct sk_buff *skb, unsigned int len)
{
skb->len -= len;
BUG_ON(skb->len < skb->data_len);
return skb->data += len;
}
Looking into the above panic triggered in skbuff.h, when this occurs
I have noticed that the value of skb->data_len is unusually large ...
__skb_pull: len 1500 (14), data_len 4294967274
I then added some traces to stmmac_napi_poll_rx() and
stmmac_rx_buf2_len() to trace the values of various various variables
and when the problem occurs I see ...
stmmac_napi_poll_rx: stmmac_rx: count 0, len 1518, buf1 66, buf2 1452
stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1518
stmmac_napi_poll_rx: stmmac_rx: count 1, len 1518, buf1 66, buf2 1452
stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1536
stmmac_napi_poll_rx: stmmac_rx: count 2, len 1602, buf1 66, buf2 1536
stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 1602, plen 1518
stmmac_napi_poll_rx: stmmac_rx: count 2, len 1518, buf1 0, buf2 4294967212
stmmac_napi_poll_rx: stmmac_rx: dma_buf_sz 1536, buf1 0, buf2 4294967212
The above shows that occasionally the value of 'len' passed to
stmmac_rx_buf2_len() is greater than the value returned by
stmmac_get_rx_frame_len() and stored in 'plen', which then causes
stmmac_rx_buf2_len() to return a negative value but is then treated
as an unsigned value. So it is clear to me that there is overflow
happening occasionally, but I am not sure how to fix it. I tried the
following but this appears to be causing other issues ...
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4749bd0af160..26336de80fe8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3728,7 +3728,7 @@ static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
/* Not last descriptor */
if (status & rx_not_ls)
- return priv->dma_buf_sz;
+ return priv->dma_buf_sz - len;
plen = stmmac_get_rx_frame_len(priv, p, coe);
@@ -3848,7 +3848,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
buf1_len = stmmac_rx_buf1_len(priv, p, status, len);
len += buf1_len;
- buf2_len = stmmac_rx_buf2_len(priv, p, status, len);
+ buf2_len = stmmac_rx_buf2_len(priv, p, status, buf1_len);
len += buf2_len;
The patch I added to trace the various variable is as follows ...
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4749bd0af160..975059bb3165 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3723,15 +3723,20 @@ static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
unsigned int plen = 0;
/* Not split header, buffer is not available */
- if (!priv->sph)
+ if (!priv->sph) {
+ trace_printk("%s: len %u, plen %u\n", __func__, len, priv->dma_buf_sz);
return 0;
+ }
/* Not last descriptor */
- if (status & rx_not_ls)
+ if (status & rx_not_ls) {
+ trace_printk("%s: len %u, plen %u\n", __func__, len, priv->dma_buf_sz);
return priv->dma_buf_sz;
+ }
plen = stmmac_get_rx_frame_len(priv, p, coe);
+ trace_printk("%s: len %u, plen %u\n", __func__, len, plen);
/* Last descriptor */
return plen - len;
}
@@ -3850,7 +3855,13 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
len += buf1_len;
buf2_len = stmmac_rx_buf2_len(priv, p, status, len);
len += buf2_len;
-
+ trace_printk("%s: count %u, len %u, buf1 %u, buf2 %u\n", __func__,
+ count, len, buf1_len, buf2_len);
+ if (buf1_len > priv->dma_buf_sz || buf2_len > priv->dma_buf_sz) {
+ trace_printk("%s: dma_buf_sz %u, buf1 %u, buf2 %u\n",
+ __func__, priv->dma_buf_sz, buf1_len, buf2_len);
+ BUG_ON(1);
+ }
/* ACS is set; GMAC core strips PAD/FCS for IEEE 802.3
* Type frames (LLC/LLC-SNAP)
*
Note I added the above BUG_ON to trap unusually large buffers. Let
me know if you have any thoughts.
Thanks!
Jon
--
nvpublic
Powered by blists - more mailing lists