August 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] drm/i915/gem: Adjust vma offset for framebuffer mmap offset" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 1ac5167b3a90c9820daa64cc65e319b2d958d686 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024081211-bonsai-riches-b3eb@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 1ac5167b3a90 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") 274d4b96b12f ("drm/i915: Fix a NULL vs IS_ERR() bug") eaee1c085863 ("drm/i915: Add a function to mmap framebuffer obj") cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.") 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend") 2a7005c8a398 ("Merge tag 'drm-intel-gt-next-2021-06-10' of git://anongit.freedesktop.org/drm/drm-intel into drm-next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1ac5167b3a90c9820daa64cc65e319b2d958d686 Mon Sep 17 00:00:00 2001 From: Andi Shyti <andi.shyti(a)linux.intel.com> Date: Fri, 2 Aug 2024 10:38:49 +0200 Subject: [PATCH] drm/i915/gem: Adjust vma offset for framebuffer mmap offset When mapping a framebuffer object, the virtual memory area (VMA) offset ('vm_pgoff') should be adjusted by the start of the 'vma_node' associated with the object. This ensures that the VMA offset is correctly aligned with the corresponding offset within the GGTT aperture. Increment vm_pgoff by the start of the vma_node with the offset= provided by the user. Suggested-by: Chris Wilson <chris.p.wilson(a)linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti(a)linux.intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt(a)intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: <stable(a)vger.kernel.org> # v4.9+ [Joonas: Add Cc: stable] Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240802083850.103694-2-andi.… (cherry picked from commit 60a2066c50058086510c91f404eb582029650970) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index a2195e28b625..ce10dd259812 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c @@ -1084,6 +1084,8 @@ int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma mmo = mmap_offset_attach(obj, mmap_type, NULL); if (IS_ERR(mmo)) return PTR_ERR(mmo); + + vma->vm_pgoff += drm_vma_node_start(&mmo->vma_node); } /*

10 months, 3 weeks

1
0
0 0

FAILED: patch "[PATCH] drm/i915/gem: Adjust vma offset for framebuffer mmap offset" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 1ac5167b3a90c9820daa64cc65e319b2d958d686 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024081210-gathering-rocklike-26ad@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 1ac5167b3a90 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") 274d4b96b12f ("drm/i915: Fix a NULL vs IS_ERR() bug") eaee1c085863 ("drm/i915: Add a function to mmap framebuffer obj") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1ac5167b3a90c9820daa64cc65e319b2d958d686 Mon Sep 17 00:00:00 2001 From: Andi Shyti <andi.shyti(a)linux.intel.com> Date: Fri, 2 Aug 2024 10:38:49 +0200 Subject: [PATCH] drm/i915/gem: Adjust vma offset for framebuffer mmap offset When mapping a framebuffer object, the virtual memory area (VMA) offset ('vm_pgoff') should be adjusted by the start of the 'vma_node' associated with the object. This ensures that the VMA offset is correctly aligned with the corresponding offset within the GGTT aperture. Increment vm_pgoff by the start of the vma_node with the offset= provided by the user. Suggested-by: Chris Wilson <chris.p.wilson(a)linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti(a)linux.intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt(a)intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: <stable(a)vger.kernel.org> # v4.9+ [Joonas: Add Cc: stable] Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240802083850.103694-2-andi.… (cherry picked from commit 60a2066c50058086510c91f404eb582029650970) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index a2195e28b625..ce10dd259812 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c @@ -1084,6 +1084,8 @@ int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma mmo = mmap_offset_attach(obj, mmap_type, NULL); if (IS_ERR(mmo)) return PTR_ERR(mmo); + + vma->vm_pgoff += drm_vma_node_start(&mmo->vma_node); } /*

10 months, 3 weeks

1
0
0 0

Fwd: mmap 0-th page

by michal.hrachovec＠volny.cz

I am apologizing for sending again. I have forgotten to add all recipients to previous e-mail. ... -------- Forwarded Message -------- Subject: Re: mmap 0-th page Date: Fri, 9 Aug 2024 12:45:01 +0200 From: michal.hrachovec(a)volny.cz <michal.hrachovec(a)volny.cz> To: Jiri Slaby <jirislaby(a)kernel.org> Good afternoon, I finally have in Fedora Linux kernel version 6.10.3: Linux fedora 6.10.3-100.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Aug 5 14:46:47 UTC 2024 x86_64 GNU/Linux I have set this setting to zero: cat /proc/sys/vm/mmap_min_addr 0 Then I compiled your program, where I only added the main and the return statements: int main(void) { char *zero = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0); *(char *)(NULL) = 'A'; printf("%c\n", *zero); return 0; } I got error at running the compiled program: Program received signal SIGSEGV, Segmentation fault (at line 2 of your program) Can you help again, please. Thank you. Michal Hrachovec On 7/31/24 09:43, Jiri Slaby wrote: > On 31. 07. 24, 9:39, Jiri Slaby wrote: >> On 26. 07. 24, 12:36, michal.hrachovec(a)volny.cz wrote: >>> I am trying to allocate the 0-th page with mmap function in my code. >>> I am always getting this error with this error-code: mmap error ffffffff >>> Then I was searching the internet for this topic and I have found >>> the same topic at stackoverflow web pages. >> >> >> char *zero = mmap(NULL, 4096, PROT_READ | PROT_WRITE, >> MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0); >> *(char *)(NULL) = 'A'; >> printf("%c\n", *zero); >> >> still yields 'A' here with 6.10.2 w/ vm.mmap_min_addr=0. > Yeah and mind LSMs... >

10 months, 3 weeks

2
1
0 0

[PATCH v2] selftests: memfd_secret: don't build memfd_secret test on unsupported arches

by Muhammad Usama Anjum

[1] mentions that memfd_secret is only supported on arm64, riscv, x86 and x86_64 for now. It doesn't support other architectures. I found the build error on arm and decided to send the fix as it was creating noise on KernelCI: memfd_secret.c: In function 'memfd_secret': memfd_secret.c:42:24: error: '__NR_memfd_secret' undeclared (first use in this function); did you mean 'memfd_secret'? 42 | return syscall(__NR_memfd_secret, flags); | ^~~~~~~~~~~~~~~~~ | memfd_secret Hence I'm adding condition that memfd_secret should only be compiled on supported architectures. Also check in run_vmtests script if memfd_secret binary is present before executing it. [1] https://lore.kernel.org/all/20210518072034.31572-7-rppt@kernel.org/ Cc: stable(a)vger.kernel.org Fixes: 76fe17ef588a ("secretmem: test: add basic selftest for memfd_secret(2)") Reviewed-by: Shuah Khan <skhan(a)linuxfoundation.org> Acked-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- Changes since v1: - Add error message to the patch and reviewed-by tags --- tools/testing/selftests/mm/Makefile | 2 ++ tools/testing/selftests/mm/run_vmtests.sh | 3 +++ 2 files changed, 5 insertions(+) diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile index 1a83b70e84535..4ea188be0588a 100644 --- a/tools/testing/selftests/mm/Makefile +++ b/tools/testing/selftests/mm/Makefile @@ -53,7 +53,9 @@ TEST_GEN_FILES += madv_populate TEST_GEN_FILES += map_fixed_noreplace TEST_GEN_FILES += map_hugetlb TEST_GEN_FILES += map_populate +ifneq (,$(filter $(ARCH),arm64 riscv riscv64 x86 x86_64)) TEST_GEN_FILES += memfd_secret +endif TEST_GEN_FILES += migration TEST_GEN_FILES += mkdirty TEST_GEN_FILES += mlock-random-test diff --git a/tools/testing/selftests/mm/run_vmtests.sh b/tools/testing/selftests/mm/run_vmtests.sh index 03ac4f2e1cce6..36045edb10dea 100755 --- a/tools/testing/selftests/mm/run_vmtests.sh +++ b/tools/testing/selftests/mm/run_vmtests.sh @@ -374,8 +374,11 @@ CATEGORY="hmm" run_test bash ./test_hmm.sh smoke # MADV_POPULATE_READ and MADV_POPULATE_WRITE tests CATEGORY="madv_populate" run_test ./madv_populate +if [ -x ./memfd_secret ] +then (echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope 2>&1) | tap_prefix CATEGORY="memfd_secret" run_test ./memfd_secret +fi # KSM KSM_MERGE_TIME_HUGE_PAGES test with size of 100 CATEGORY="ksm" run_test ./ksm_tests -H -s 100 -- 2.39.2

10 months, 3 weeks

1
0
0 0

[PATCH v4 0/6] Refine i.MX8QM SATA based on generic PHY callbacks

by Richard Zhu

V4 main changes: Thanks for Niklas' comments. - Update the commit message in #2 patch of v4. - Split the clean up unrelated codes to #3 and #4 of v4. - Remove the Cc: stable(a)vger.kernel.org and Fixes tag in #5 of v4. V3 main changes: - Use GENMASK() macro to define the _MASK. - Refine the macro names. V2 main changes: - Add Rob's reviewed-by in the binding patch. - Re-name the error out lables and new RXWM macro more descriptive. - In #3 patch, add one fix tag, and CC stable kernel. Based on i.MX8QM HSIO PHY driver, refine i.MX8QM SATA driver by using PHY interface. [PATCH v4 1/6] dt-bindings: ata: Add i.MX8QM AHCI compatible string [PATCH v4 2/6] ata: ahci_imx: Clean up code by using i.MX8Q HSIO PHY [PATCH v4 3/6] ata: ahci_imx: AHB clock rate setting is not required [PATCH v4 4/6] ata: ahci_imx: Add 32bits DMA limit for i.MX8QM AHCI [PATCH v4 5/6] ata: ahci_imx: Enlarge RX water mark for i.MX8QM SATA [PATCH v4 6/6] ata: ahci_imx: Correct the email address Documentation/devicetree/bindings/ata/imx-sata.yaml | 47 +++++++++++ drivers/ata/ahci_imx.c | 406 ++++++++++++++++++++++++----------------------------------------------------------------- 2 files changed, 155 insertions(+), 298 deletions(-)

10 months, 3 weeks

5
16
0 0

Re: Patch "selftests: mptcp: join: ability to invert ADD_ADDR check" has been added to the 6.10-stable tree

by Matthieu Baerts

Hi Sasha, Greg, On 11/08/2024 14:56, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > selftests: mptcp: join: ability to invert ADD_ADDR check > > to the 6.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > selftests-mptcp-join-ability-to-invert-add_addr-chec.patch > and it can be found in the queue-6.10 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 469e6fe99988649029b7f136218d5c3d8854e705 > Author: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> > Date: Wed Jul 31 13:05:58 2024 +0200 > > selftests: mptcp: join: ability to invert ADD_ADDR check > > [ Upstream commit bec1f3b119ebc613d08dfbcdbaef01a79aa7de92 ] > > In the following commit, the client will initiate the ADD_ADDR, instead > of the server. We need to way to verify the ADD_ADDR have been correctly > sent. > > Note: the default expected counters for when the port number is given > are never changed by the caller, no need to accept them as parameter > then. > > The 'Fixes' tag here below is the same as the one from the previous > commit: this patch here is not fixing anything wrong in the selftests, > but it validates the previous fix for an issue introduced by this commit > ID. Sorry, I just realised I forgot to add the "Cc: Stable" on all patches from this series :-/ This patch and "selftests: mptcp: join: test both signal & subflow" should be backported with the other patches modifying files in net/mptcp. Without them, the two patches that have just been added to the queue will just make the selftests failing. Is it then possible to drop these two patches from the 6.10, 6.6 and 6.1 queues for the moment please? I can send patches for these versions later on. selftests-mptcp-join-ability-to-invert-add_addr-chec.patch: 6.10, 6.6 selftests-mptcp-join-test-both-signal-subflow.patch: 6.10, 6.6 and 6.1 > Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk") > Reviewed-by: Mat Martineau <martineau(a)kernel.org> > Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> > Link: https://patch.msgid.link/20240731-upstream-net-20240731-mptcp-endp-subflow-… > Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> Cheers, Matt -- Sponsored by the NGI0 Core fund.

10 months, 3 weeks

2
1
0 0

Re: Patch "irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc()" has been added to the 6.10-stable tree

by Marc Zyngier

On Sun, 11 Aug 2024 13:57:45 +0100, Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() > > to the 6.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > irqchip-gic-v3-don-t-return-errors-from-gic_acpi_mat.patch > and it can be found in the queue-6.10 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Why, oh why??? Yesterday, you agreed *not* to merge this patch as: https://lore.kernel.org/r/Zrcuvkiol0PsKu0l@sashalap And yet you picked it up again? M. -- Without deviation from the norm, progress is not possible.

10 months, 3 weeks

2
1
0 0

Longterm 6.6.x series: hdd temperature not accessible any more

by Wolfgang Klein

Hello, on kernel.org I was told to write to these addresses and report about a minor problem with the latest version of the kernel I use. I am using my own compiled kernels ever since, and right now I am using the LTS series 6.6.x. After 6.6.43 tools like hddtemp stopp working: they all tell me that the drive are sleeping, which they are certainly not. Even netcat can't tell me the temperature any more. In a small script I use these commands: /bin/netcat -4d localhost 7634 | awk -F '|' '{print $4 " °C"}' /bin/netcat -4d localhost 7634 | awk -F '|' '{print $9 " °C"}' Those commands work very well on kernel 6.6.43, and they don't work any more on 6.6.44 and 6.6.45. The error is reproduceable: when I boot into 6.6.43 the temperature is retrieved, when I reboot into 6.6.44 or 6.6.45 the commands stopp working. The tool hddtemp even claims that the "drive is sleeping", and it does so for both drives. Is this a bug or has a new parameter or configuration option been added to the kernel code that has to be activated in order to retrieve the temperature? Attached you'll find my kernel configuration from version 6.6.43, where the hdd temperature is still retrieved by the above command. My system: Kernel Version: 6.6.43 (64-bit) Processors: 4 × Intel® Core™ i5-6500 CPU @ 3.20GHz Manufacturer: FUJITSU Product Name: ESPRIMO_D756 /dev/sda: Model=Samsung SSD 870 EVO 500GB, FwRev=SVT01B6Q, SerialNo=S62BNJ0NC06737D Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=no WriteCache=enabled Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7 /dev/sdb: Model=TOSHIBA MK5061GSYB, FwRev=ME0A, SerialNo=42JNT0TGT Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773167 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=yes: unknown setting WriteCache=enabled Drive conforms to: Unspecified: ATA/ATAPI-3,4,5,6,7 Thank you very much for any help in advance! If you need any more information, just let me know! Kind regards, Wolfgang

10 months, 3 weeks

2
1
0 0

[PATCH] selftests: memfd_secret: don't build memfd_secret test on unsupported arches

by Muhammad Usama Anjum

[1] mentions that memfd_secret is only supported on arm64, riscv, x86 and x86_64 for now. It doesn't support other architectures. I found the build error on arm and decided to send the fix as it was creating noise on KernelCI. Hence I'm adding condition that memfd_secret should only be compiled on supported architectures. Also check in run_vmtests script if memfd_secret binary is present before executing it. [1] https://lore.kernel.org/all/20210518072034.31572-7-rppt@kernel.org/ Cc: stable(a)vger.kernel.org Fixes: 76fe17ef588a ("secretmem: test: add basic selftest for memfd_secret(2)") Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- tools/testing/selftests/mm/Makefile | 2 ++ tools/testing/selftests/mm/run_vmtests.sh | 3 +++ 2 files changed, 5 insertions(+) diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile index 1a83b70e84535..4ea188be0588a 100644 --- a/tools/testing/selftests/mm/Makefile +++ b/tools/testing/selftests/mm/Makefile @@ -53,7 +53,9 @@ TEST_GEN_FILES += madv_populate TEST_GEN_FILES += map_fixed_noreplace TEST_GEN_FILES += map_hugetlb TEST_GEN_FILES += map_populate +ifneq (,$(filter $(ARCH),arm64 riscv riscv64 x86 x86_64)) TEST_GEN_FILES += memfd_secret +endif TEST_GEN_FILES += migration TEST_GEN_FILES += mkdirty TEST_GEN_FILES += mlock-random-test diff --git a/tools/testing/selftests/mm/run_vmtests.sh b/tools/testing/selftests/mm/run_vmtests.sh index 03ac4f2e1cce6..36045edb10dea 100755 --- a/tools/testing/selftests/mm/run_vmtests.sh +++ b/tools/testing/selftests/mm/run_vmtests.sh @@ -374,8 +374,11 @@ CATEGORY="hmm" run_test bash ./test_hmm.sh smoke # MADV_POPULATE_READ and MADV_POPULATE_WRITE tests CATEGORY="madv_populate" run_test ./madv_populate +if [ -x ./memfd_secret ] +then (echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope 2>&1) | tap_prefix CATEGORY="memfd_secret" run_test ./memfd_secret +fi # KSM KSM_MERGE_TIME_HUGE_PAGES test with size of 100 CATEGORY="ksm" run_test ./ksm_tests -H -s 100 -- 2.39.2

10 months, 3 weeks

3
2
0 0

FAILED: patch "[PATCH] net: drop bad gso csum_start and offset in virtio_net_hdr" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 89add40066f9ed9abe5f7f886fe5789ff7e0c50e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024081148-unhappily-maturity-a413@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 89add40066f9 ("net: drop bad gso csum_start and offset in virtio_net_hdr") fc8b2a619469 ("net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation") 9840036786d9 ("gso: fix dodgy bit handling for GSO_UDP_L4") cf9acc90c80e ("net: virtio_net_hdr_to_skb: count transport header in UFO") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 89add40066f9ed9abe5f7f886fe5789ff7e0c50e Mon Sep 17 00:00:00 2001 From: Willem de Bruijn <willemb(a)google.com> Date: Mon, 29 Jul 2024 16:10:12 -0400 Subject: [PATCH] net: drop bad gso csum_start and offset in virtio_net_hdr Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb for GSO packets. The function already checks that a checksum requested with VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation. Syzkaller demonstrated to reach this warning in skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) By injecting a TSO packet: WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [inline] netdev_start_xmit include/linux/netdevice.h:4864 [inline] xmit_one net/core/dev.c:3595 [inline] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261 packet_snd net/packet/af_packet.c:3073 [inline] The geometry of the bad input packet at tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0) Mitigate with stricter input validation. csum_offset: for GSO packets, deduce the correct value from gso_type. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]_ufo_fragment ignores these fields and always computes the checksum in software. csum_start: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload. GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no need to test for ip_summed == CHECKSUM_PARTIAL first. This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests. Link: https://syzkaller.appspot.com/bug?extid=e1db31216c789f552871 Link: https://lore.kernel.org/netdev/20240723223109.2196886-1-kuba@kernel.org Fixes: e269d79c7d35 ("net: missing check virtio") Cc: stable(a)vger.kernel.org Signed-off-by: Willem de Bruijn <willemb(a)google.com> Link: https://patch.msgid.link/20240729201108.1615114-1-willemdebruijn.kernel@gma… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h index d1d7825318c3..6c395a2600e8 100644 --- a/include/linux/virtio_net.h +++ b/include/linux/virtio_net.h @@ -56,7 +56,6 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, unsigned int thlen = 0; unsigned int p_off = 0; unsigned int ip_proto; - u64 ret, remainder, gso_size; if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) { switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) { @@ -99,16 +98,6 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, u32 off = __virtio16_to_cpu(little_endian, hdr->csum_offset); u32 needed = start + max_t(u32, thlen, off + sizeof(__sum16)); - if (hdr->gso_size) { - gso_size = __virtio16_to_cpu(little_endian, hdr->gso_size); - ret = div64_u64_rem(skb->len, gso_size, &remainder); - if (!(ret && (hdr->gso_size > needed) && - ((remainder > needed) || (remainder == 0)))) { - return -EINVAL; - } - skb_shinfo(skb)->tx_flags |= SKBFL_SHARED_FRAG; - } - if (!pskb_may_pull(skb, needed)) return -EINVAL; @@ -182,6 +171,11 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, if (gso_type != SKB_GSO_UDP_L4) return -EINVAL; break; + case SKB_GSO_TCPV4: + case SKB_GSO_TCPV6: + if (skb->csum_offset != offsetof(struct tcphdr, check)) + return -EINVAL; + break; } /* Kernel has a special handling for GSO_BY_FRAGS. */ diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c index 4b791e74529e..e4ad3311e148 100644 --- a/net/ipv4/tcp_offload.c +++ b/net/ipv4/tcp_offload.c @@ -140,6 +140,9 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb, if (thlen < sizeof(*th)) goto out; + if (unlikely(skb_checksum_start(skb) != skb_transport_header(skb))) + goto out; + if (!pskb_may_pull(skb, thlen)) goto out; diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index aa2e0a28ca61..bc8a9da750fe 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -278,6 +278,10 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb, if (gso_skb->len <= sizeof(*uh) + mss) return ERR_PTR(-EINVAL); + if (unlikely(skb_checksum_start(gso_skb) != + skb_transport_header(gso_skb))) + return ERR_PTR(-EINVAL); + if (skb_gso_ok(gso_skb, features | NETIF_F_GSO_ROBUST)) { /* Packet is from an untrusted source, reset gso_segs. */ skb_shinfo(gso_skb)->gso_segs = DIV_ROUND_UP(gso_skb->len - sizeof(*uh),

10 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024