From c0425aa61e26e6b830fc9d98e6d77c9438625ef7 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 12 Mar 2022 12:16:51 +0100 Subject: [PATCH] 5.4-stable patches added patches: arm64-dts-marvell-armada-37xx-remap-io-space-to-bus-address-0x0.patch fuse-fix-pipe-buffer-lifetime-for-direct_io.patch mmc-meson-fix-usage-of-meson_mmc_post_req.patch net-macb-fix-lost-rx-packet-wakeup-race-in-napi-receive.patch riscv-fix-auipc-jalr-relocation-range-checks.patch staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch --- ...xx-remap-io-space-to-bus-address-0x0.patch | 76 +++++++++++++ ...x-pipe-buffer-lifetime-for-direct_io.patch | 79 ++++++++++++++ ...eson-fix-usage-of-meson_mmc_post_req.patch | 81 ++++++++++++++ ...x-packet-wakeup-race-in-napi-receive.patch | 81 ++++++++++++++ ...x-auipc-jalr-relocation-range-checks.patch | 100 ++++++++++++++++++ queue-5.4/series | 6 ++ ...24x-fix-use-after-free-in-gdm_lte_rx.patch | 42 ++++++++ 7 files changed, 465 insertions(+) create mode 100644 queue-5.4/arm64-dts-marvell-armada-37xx-remap-io-space-to-bus-address-0x0.patch create mode 100644 queue-5.4/fuse-fix-pipe-buffer-lifetime-for-direct_io.patch create mode 100644 queue-5.4/mmc-meson-fix-usage-of-meson_mmc_post_req.patch create mode 100644 queue-5.4/net-macb-fix-lost-rx-packet-wakeup-race-in-napi-receive.patch create mode 100644 queue-5.4/riscv-fix-auipc-jalr-relocation-range-checks.patch create mode 100644 queue-5.4/staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch diff --git a/queue-5.4/arm64-dts-marvell-armada-37xx-remap-io-space-to-bus-address-0x0.patch b/queue-5.4/arm64-dts-marvell-armada-37xx-remap-io-space-to-bus-address-0x0.patch new file mode 100644 index 00000000000..402e90bd059 --- /dev/null +++ b/queue-5.4/arm64-dts-marvell-armada-37xx-remap-io-space-to-bus-address-0x0.patch @@ -0,0 +1,76 @@ +From a1cc1697bb56cdf880ad4d17b79a39ef2c294bc9 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +Date: Thu, 10 Mar 2022 11:39:23 +0100 +Subject: arm64: dts: marvell: armada-37xx: Remap IO space to bus address 0x0 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +commit a1cc1697bb56cdf880ad4d17b79a39ef2c294bc9 upstream. + +Legacy and old PCI I/O based cards do not support 32-bit I/O addressing. + +Since commit 64f160e19e92 ("PCI: aardvark: Configure PCIe resources from +'ranges' DT property") kernel can set different PCIe address on CPU and +different on the bus for the one A37xx address mapping without any firmware +support in case the bus address does not conflict with other A37xx mapping. + +So remap I/O space to the bus address 0x0 to enable support for old legacy +I/O port based cards which have hardcoded I/O ports in low address space. + +Note that DDR on A37xx is mapped to bus address 0x0. And mapping of I/O +space can be set to address 0x0 too because MEM space and I/O space are +separate and so do not conflict. + +Remapping IO space on Turris Mox to different address is not possible to +due bootloader bug. + +Signed-off-by: Pali Rohár +Reported-by: Arnd Bergmann +Fixes: 76f6386b25cc ("arm64: dts: marvell: Add Aardvark PCIe support for Armada 3700") +Cc: stable@vger.kernel.org # 64f160e19e92 ("PCI: aardvark: Configure PCIe resources from 'ranges' DT property") +Cc: stable@vger.kernel.org # 514ef1e62d65 ("arm64: dts: marvell: armada-37xx: Extend PCIe MEM space") +Reviewed-by: Arnd Bergmann +Signed-off-by: Gregory CLEMENT +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 7 ++++++- + arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 2 +- + 2 files changed, 7 insertions(+), 2 deletions(-) + +--- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts ++++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts +@@ -138,7 +138,9 @@ + /* + * U-Boot port for Turris Mox has a bug which always expects that "ranges" DT property + * contains exactly 2 ranges with 3 (child) address cells, 2 (parent) address cells and +- * 2 size cells and also expects that the second range starts at 16 MB offset. If these ++ * 2 size cells and also expects that the second range starts at 16 MB offset. Also it ++ * expects that first range uses same address for PCI (child) and CPU (parent) cells (so ++ * no remapping) and that this address is the lowest from all specified ranges. If these + * conditions are not met then U-Boot crashes during loading kernel DTB file. PCIe address + * space is 128 MB long, so the best split between MEM and IO is to use fixed 16 MB window + * for IO and the rest 112 MB (64+32+16) for MEM, despite that maximal IO size is just 64 kB. +@@ -147,6 +149,9 @@ + * https://source.denx.de/u-boot/u-boot/-/commit/cb2ddb291ee6fcbddd6d8f4ff49089dfe580f5d7 + * https://source.denx.de/u-boot/u-boot/-/commit/c64ac3b3185aeb3846297ad7391fc6df8ecd73bf + * https://source.denx.de/u-boot/u-boot/-/commit/4a82fca8e330157081fc132a591ebd99ba02ee33 ++ * Bug related to requirement of same child and parent addresses for first range is fixed ++ * in U-Boot version 2022.04 by following commit: ++ * https://source.denx.de/u-boot/u-boot/-/commit/1fd54253bca7d43d046bba4853fe5fafd034bc17 + */ + #address-cells = <3>; + #size-cells = <2>; +--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi ++++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi +@@ -495,7 +495,7 @@ + * (totaling 127 MiB) for MEM. + */ + ranges = <0x82000000 0 0xe8000000 0 0xe8000000 0 0x07f00000 /* Port 0 MEM */ +- 0x81000000 0 0xefff0000 0 0xefff0000 0 0x00010000>; /* Port 0 IO */ ++ 0x81000000 0 0x00000000 0 0xefff0000 0 0x00010000>; /* Port 0 IO */ + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc 0>, + <0 0 0 2 &pcie_intc 1>, diff --git a/queue-5.4/fuse-fix-pipe-buffer-lifetime-for-direct_io.patch b/queue-5.4/fuse-fix-pipe-buffer-lifetime-for-direct_io.patch new file mode 100644 index 00000000000..6dc0c5ec65e --- /dev/null +++ b/queue-5.4/fuse-fix-pipe-buffer-lifetime-for-direct_io.patch @@ -0,0 +1,79 @@ +From 0c4bcfdecb1ac0967619ee7ff44871d93c08c909 Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Mon, 7 Mar 2022 16:30:44 +0100 +Subject: fuse: fix pipe buffer lifetime for direct_io + +From: Miklos Szeredi + +commit 0c4bcfdecb1ac0967619ee7ff44871d93c08c909 upstream. + +In FOPEN_DIRECT_IO mode, fuse_file_write_iter() calls +fuse_direct_write_iter(), which normally calls fuse_direct_io(), which then +imports the write buffer with fuse_get_user_pages(), which uses +iov_iter_get_pages() to grab references to userspace pages instead of +actually copying memory. + +On the filesystem device side, these pages can then either be read to +userspace (via fuse_dev_read()), or splice()d over into a pipe using +fuse_dev_splice_read() as pipe buffers with &nosteal_pipe_buf_ops. + +This is wrong because after fuse_dev_do_read() unlocks the FUSE request, +the userspace filesystem can mark the request as completed, causing write() +to return. At that point, the userspace filesystem should no longer have +access to the pipe buffer. + +Fix by copying pages coming from the user address space to new pipe +buffers. + +Reported-by: Jann Horn +Fixes: c3021629a0d8 ("fuse: support splice() reading from fuse device") +Cc: +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman +--- + fs/fuse/dev.c | 12 +++++++++++- + fs/fuse/file.c | 1 + + fs/fuse/fuse_i.h | 1 + + 3 files changed, 13 insertions(+), 1 deletion(-) + +--- a/fs/fuse/dev.c ++++ b/fs/fuse/dev.c +@@ -933,7 +933,17 @@ static int fuse_copy_page(struct fuse_co + + while (count) { + if (cs->write && cs->pipebufs && page) { +- return fuse_ref_page(cs, page, offset, count); ++ /* ++ * Can't control lifetime of pipe buffers, so always ++ * copy user pages. ++ */ ++ if (cs->req->args->user_pages) { ++ err = fuse_copy_fill(cs); ++ if (err) ++ return err; ++ } else { ++ return fuse_ref_page(cs, page, offset, count); ++ } + } else if (!cs->len) { + if (cs->move_pages && page && + offset == 0 && count == PAGE_SIZE) { +--- a/fs/fuse/file.c ++++ b/fs/fuse/file.c +@@ -1433,6 +1433,7 @@ static int fuse_get_user_pages(struct fu + (PAGE_SIZE - ret) & (PAGE_SIZE - 1); + } + ++ ap->args.user_pages = true; + if (write) + ap->args.in_pages = 1; + else +--- a/fs/fuse/fuse_i.h ++++ b/fs/fuse/fuse_i.h +@@ -248,6 +248,7 @@ struct fuse_args { + bool nocreds:1; + bool in_pages:1; + bool out_pages:1; ++ bool user_pages:1; + bool out_argvar:1; + bool page_zeroing:1; + bool page_replace:1; diff --git a/queue-5.4/mmc-meson-fix-usage-of-meson_mmc_post_req.patch b/queue-5.4/mmc-meson-fix-usage-of-meson_mmc_post_req.patch new file mode 100644 index 00000000000..f7c18aeb07b --- /dev/null +++ b/queue-5.4/mmc-meson-fix-usage-of-meson_mmc_post_req.patch @@ -0,0 +1,81 @@ +From f0d2f15362f02444c5d7ffd5a5eb03e4aa54b685 Mon Sep 17 00:00:00 2001 +From: Rong Chen +Date: Wed, 16 Feb 2022 20:42:39 +0800 +Subject: mmc: meson: Fix usage of meson_mmc_post_req() + +From: Rong Chen + +commit f0d2f15362f02444c5d7ffd5a5eb03e4aa54b685 upstream. + +Currently meson_mmc_post_req() is called in meson_mmc_request() right +after meson_mmc_start_cmd(). This could lead to DMA unmapping before the request +is actually finished. + +To fix, don't call meson_mmc_post_req() until meson_mmc_request_done(). + +Signed-off-by: Rong Chen +Reviewed-by: Kevin Hilman +Fixes: 79ed05e329c3 ("mmc: meson-gx: add support for descriptor chain mode") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220216124239.4007667-1-rong.chen@amlogic.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/meson-gx-mmc.c | 15 ++++++++------- + 1 file changed, 8 insertions(+), 7 deletions(-) + +--- a/drivers/mmc/host/meson-gx-mmc.c ++++ b/drivers/mmc/host/meson-gx-mmc.c +@@ -174,6 +174,8 @@ struct meson_host { + int irq; + + bool vqmmc_enabled; ++ bool needs_pre_post_req; ++ + }; + + #define CMD_CFG_LENGTH_MASK GENMASK(8, 0) +@@ -655,6 +657,8 @@ static void meson_mmc_request_done(struc + struct meson_host *host = mmc_priv(mmc); + + host->cmd = NULL; ++ if (host->needs_pre_post_req) ++ meson_mmc_post_req(mmc, mrq, 0); + mmc_request_done(host->mmc, mrq); + } + +@@ -872,7 +876,7 @@ static int meson_mmc_validate_dram_acces + static void meson_mmc_request(struct mmc_host *mmc, struct mmc_request *mrq) + { + struct meson_host *host = mmc_priv(mmc); +- bool needs_pre_post_req = mrq->data && ++ host->needs_pre_post_req = mrq->data && + !(mrq->data->host_cookie & SD_EMMC_PRE_REQ_DONE); + + /* +@@ -888,22 +892,19 @@ static void meson_mmc_request(struct mmc + } + } + +- if (needs_pre_post_req) { ++ if (host->needs_pre_post_req) { + meson_mmc_get_transfer_mode(mmc, mrq); + if (!meson_mmc_desc_chain_mode(mrq->data)) +- needs_pre_post_req = false; ++ host->needs_pre_post_req = false; + } + +- if (needs_pre_post_req) ++ if (host->needs_pre_post_req) + meson_mmc_pre_req(mmc, mrq); + + /* Stop execution */ + writel(0, host->regs + SD_EMMC_START); + + meson_mmc_start_cmd(mmc, mrq->sbc ?: mrq->cmd); +- +- if (needs_pre_post_req) +- meson_mmc_post_req(mmc, mrq, 0); + } + + static void meson_mmc_read_resp(struct mmc_host *mmc, struct mmc_command *cmd) diff --git a/queue-5.4/net-macb-fix-lost-rx-packet-wakeup-race-in-napi-receive.patch b/queue-5.4/net-macb-fix-lost-rx-packet-wakeup-race-in-napi-receive.patch new file mode 100644 index 00000000000..31f49865c46 --- /dev/null +++ b/queue-5.4/net-macb-fix-lost-rx-packet-wakeup-race-in-napi-receive.patch @@ -0,0 +1,81 @@ +From 0bf476fc3624e3a72af4ba7340d430a91c18cd67 Mon Sep 17 00:00:00 2001 +From: Robert Hancock +Date: Thu, 3 Mar 2022 12:10:27 -0600 +Subject: net: macb: Fix lost RX packet wakeup race in NAPI receive + +From: Robert Hancock + +commit 0bf476fc3624e3a72af4ba7340d430a91c18cd67 upstream. + +There is an oddity in the way the RSR register flags propagate to the +ISR register (and the actual interrupt output) on this hardware: it +appears that RSR register bits only result in ISR being asserted if the +interrupt was actually enabled at the time, so enabling interrupts with +RSR bits already set doesn't trigger an interrupt to be raised. There +was already a partial fix for this race in the macb_poll function where +it checked for RSR bits being set and re-triggered NAPI receive. +However, there was a still a race window between checking RSR and +actually enabling interrupts, where a lost wakeup could happen. It's +necessary to check again after enabling interrupts to see if RSR was set +just prior to the interrupt being enabled, and re-trigger receive in that +case. + +This issue was noticed in a point-to-point UDP request-response protocol +which periodically saw timeouts or abnormally high response times due to +received packets not being processed in a timely fashion. In many +applications, more packets arriving, including TCP retransmissions, would +cause the original packet to be processed, thus masking the issue. + +Fixes: 02f7a34f34e3 ("net: macb: Re-enable RX interrupt only when RX is done") +Cc: stable@vger.kernel.org +Co-developed-by: Scott McNutt +Signed-off-by: Scott McNutt +Signed-off-by: Robert Hancock +Tested-by: Claudiu Beznea +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/cadence/macb_main.c | 25 ++++++++++++++++++++++++- + 1 file changed, 24 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/cadence/macb_main.c ++++ b/drivers/net/ethernet/cadence/macb_main.c +@@ -1283,7 +1283,14 @@ static int macb_poll(struct napi_struct + if (work_done < budget) { + napi_complete_done(napi, work_done); + +- /* Packets received while interrupts were disabled */ ++ /* RSR bits only seem to propagate to raise interrupts when ++ * interrupts are enabled at the time, so if bits are already ++ * set due to packets received while interrupts were disabled, ++ * they will not cause another interrupt to be generated when ++ * interrupts are re-enabled. ++ * Check for this case here. This has been seen to happen ++ * around 30% of the time under heavy network load. ++ */ + status = macb_readl(bp, RSR); + if (status) { + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE) +@@ -1291,6 +1298,22 @@ static int macb_poll(struct napi_struct + napi_reschedule(napi); + } else { + queue_writel(queue, IER, bp->rx_intr_mask); ++ ++ /* In rare cases, packets could have been received in ++ * the window between the check above and re-enabling ++ * interrupts. Therefore, a double-check is required ++ * to avoid losing a wakeup. This can potentially race ++ * with the interrupt handler doing the same actions ++ * if an interrupt is raised just after enabling them, ++ * but this should be harmless. ++ */ ++ status = macb_readl(bp, RSR); ++ if (unlikely(status)) { ++ queue_writel(queue, IDR, bp->rx_intr_mask); ++ if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE) ++ queue_writel(queue, ISR, MACB_BIT(RCOMP)); ++ napi_schedule(napi); ++ } + } + } + diff --git a/queue-5.4/riscv-fix-auipc-jalr-relocation-range-checks.patch b/queue-5.4/riscv-fix-auipc-jalr-relocation-range-checks.patch new file mode 100644 index 00000000000..4913208a6ba --- /dev/null +++ b/queue-5.4/riscv-fix-auipc-jalr-relocation-range-checks.patch @@ -0,0 +1,100 @@ +From 0966d385830de3470b7131db8e86c0c5bc9c52dc Mon Sep 17 00:00:00 2001 +From: Emil Renner Berthing +Date: Wed, 23 Feb 2022 20:12:57 +0100 +Subject: riscv: Fix auipc+jalr relocation range checks + +From: Emil Renner Berthing + +commit 0966d385830de3470b7131db8e86c0c5bc9c52dc upstream. + +RISC-V can do PC-relative jumps with a 32bit range using the following +two instructions: + + auipc t0, imm20 ; t0 = PC + imm20 * 2^12 + jalr ra, t0, imm12 ; ra = PC + 4, PC = t0 + imm12 + +Crucially both the 20bit immediate imm20 and the 12bit immediate imm12 +are treated as two's-complement signed values. For this reason the +immediates are usually calculated like this: + + imm20 = (offset + 0x800) >> 12 + imm12 = offset & 0xfff + +..where offset is the signed offset from the auipc instruction. When +the 11th bit of offset is 0 the addition of 0x800 doesn't change the top +20 bits and imm12 considered positive. When the 11th bit is 1 the carry +of the addition by 0x800 means imm20 is one higher, but since imm12 is +then considered negative the two's complement representation means it +all cancels out nicely. + +However, this addition by 0x800 (2^11) means an offset greater than or +equal to 2^31 - 2^11 would overflow so imm20 is considered negative and +result in a backwards jump. Similarly the lower range of offset is also +moved down by 2^11 and hence the true 32bit range is + + [-2^31 - 2^11, 2^31 - 2^11) + +Signed-off-by: Emil Renner Berthing +Fixes: e2c0cdfba7f6 ("RISC-V: User-facing API") +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/kernel/module.c | 21 ++++++++++++++++----- + 1 file changed, 16 insertions(+), 5 deletions(-) + +--- a/arch/riscv/kernel/module.c ++++ b/arch/riscv/kernel/module.c +@@ -13,6 +13,19 @@ + #include + #include + ++/* ++ * The auipc+jalr instruction pair can reach any PC-relative offset ++ * in the range [-2^31 - 2^11, 2^31 - 2^11) ++ */ ++static bool riscv_insn_valid_32bit_offset(ptrdiff_t val) ++{ ++#ifdef CONFIG_32BIT ++ return true; ++#else ++ return (-(1L << 31) - (1L << 11)) <= val && val < ((1L << 31) - (1L << 11)); ++#endif ++} ++ + static int apply_r_riscv_32_rela(struct module *me, u32 *location, Elf_Addr v) + { + if (v != (u32)v) { +@@ -95,7 +108,7 @@ static int apply_r_riscv_pcrel_hi20_rela + ptrdiff_t offset = (void *)v - (void *)location; + s32 hi20; + +- if (offset != (s32)offset) { ++ if (!riscv_insn_valid_32bit_offset(offset)) { + pr_err( + "%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n", + me->name, (long long)v, location); +@@ -197,10 +210,9 @@ static int apply_r_riscv_call_plt_rela(s + Elf_Addr v) + { + ptrdiff_t offset = (void *)v - (void *)location; +- s32 fill_v = offset; + u32 hi20, lo12; + +- if (offset != fill_v) { ++ if (!riscv_insn_valid_32bit_offset(offset)) { + /* Only emit the plt entry if offset over 32-bit range */ + if (IS_ENABLED(CONFIG_MODULE_SECTIONS)) { + offset = module_emit_plt_entry(me, v); +@@ -224,10 +236,9 @@ static int apply_r_riscv_call_rela(struc + Elf_Addr v) + { + ptrdiff_t offset = (void *)v - (void *)location; +- s32 fill_v = offset; + u32 hi20, lo12; + +- if (offset != fill_v) { ++ if (!riscv_insn_valid_32bit_offset(offset)) { + pr_err( + "%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n", + me->name, (long long)v, location); diff --git a/queue-5.4/series b/queue-5.4/series index 0df13857506..7f4c8efd0e4 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -27,3 +27,9 @@ tracing-ensure-trace-buffer-is-at-least-4096-bytes-l.patch selftest-vm-fix-map_fixed_noreplace-test-failure.patch selftests-memfd-clean-up-mapping-in-mfd_fail_write.patch arm-spectre-bhb-provide-empty-stub-for-non-config.patch +fuse-fix-pipe-buffer-lifetime-for-direct_io.patch +staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch +net-macb-fix-lost-rx-packet-wakeup-race-in-napi-receive.patch +mmc-meson-fix-usage-of-meson_mmc_post_req.patch +riscv-fix-auipc-jalr-relocation-range-checks.patch +arm64-dts-marvell-armada-37xx-remap-io-space-to-bus-address-0x0.patch diff --git a/queue-5.4/staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch b/queue-5.4/staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch new file mode 100644 index 00000000000..da3f60891f4 --- /dev/null +++ b/queue-5.4/staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch @@ -0,0 +1,42 @@ +From fc7f750dc9d102c1ed7bbe4591f991e770c99033 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Mon, 28 Feb 2022 10:43:31 +0300 +Subject: staging: gdm724x: fix use after free in gdm_lte_rx() + +From: Dan Carpenter + +commit fc7f750dc9d102c1ed7bbe4591f991e770c99033 upstream. + +The netif_rx_ni() function frees the skb so we can't dereference it to +save the skb->len. + +Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver") +Cc: stable +Reported-by: kernel test robot +Signed-off-by: Dan Carpenter +Link: https://lore.kernel.org/r/20220228074331.GA13685@kili +Signed-off-by: Greg Kroah-Hartman +--- + drivers/staging/gdm724x/gdm_lte.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/staging/gdm724x/gdm_lte.c ++++ b/drivers/staging/gdm724x/gdm_lte.c +@@ -76,14 +76,15 @@ static void tx_complete(void *arg) + + static int gdm_lte_rx(struct sk_buff *skb, struct nic *nic, int nic_type) + { +- int ret; ++ int ret, len; + ++ len = skb->len + ETH_HLEN; + ret = netif_rx_ni(skb); + if (ret == NET_RX_DROP) { + nic->stats.rx_dropped++; + } else { + nic->stats.rx_packets++; +- nic->stats.rx_bytes += skb->len + ETH_HLEN; ++ nic->stats.rx_bytes += len; + } + + return 0; -- 2.47.3