kernel_samsung_sm7125

jenna

Maciej Żenczykowski a6748c84e5 FROMGIT: bpf: Do not change gso_size during bpf_skb_change_proto() This is technically a backwards incompatible change in behaviour, but I'm going to argue that it is very unlikely to break things, and likely to fix far more then it breaks. In no particular order, various reasons follow: (a) I've long had a bug assigned to myself to debug a super rare kernel crash on Android Pixel phones which can (per stacktrace) be traced back to BPF clat IPv6 to IPv4 protocol conversion causing some sort of ugly failure much later on during transmit deep in the GSO engine, AFAICT precisely because of this change to gso_size, though I've never been able to manually reproduce it. I believe it may be related to the particular network offload support of attached USB ethernet dongle being used for tethering off of an IPv6-only cellular connection. The reason might be we end up with more segments than max permitted, or with a GSO packet with only one segment... (either way we break some assumption and hit a BUG_ON) (b) There is no check that the gso_size is > 20 when reducing it by 20, so we might end up with a negative (or underflowing) gso_size or a gso_size of 0. This can't possibly be good. Indeed this is probably somehow exploitable (or at least can result in a kernel crash) by delivering crafted packets and perhaps triggering an infinite loop or a divide by zero... As a reminder: gso_size (MSS) is related to MTU, but not directly derived from it: gso_size/MSS may be significantly smaller then one would get by deriving from local MTU. And on some NICs (which do loose MTU checking on receive, it may even potentially be larger, for example my work pc with 1500 MTU can receive 1520 byte frames [and sometimes does due to bugs in a vendor plat46 implementation]). Indeed even just going from 21 to 1 is potentially problematic because it increases the number of segments by a factor of 21 (think DoS, or some other crash due to too many segments). (c) It's always safe to not increase the gso_size, because it doesn't result in the max packet size increasing. So the skb_increase_gso_size() call was always unnecessary for correctness (and outright undesirable, see later). As such the only part which is potentially dangerous (ie. could cause backwards compatibility issues) is the removal of the skb_decrease_gso_size() call. (d) If the packets are ultimately destined to the local device, then there is absolutely no benefit to playing around with gso_size. It only matters if the packets will egress the device. ie. we're either forwarding, or transmitting from the device. (e) This logic only triggers for packets which are GSO. It does not trigger for skbs which are not GSO. It will not convert a non-GSO MTU sized packet into a GSO packet (and you don't even know what the MTU is, so you can't even fix it). As such your transmit path must already be able to handle an MTU 20 bytes larger then your receive path (for IPv4 to IPv6 translation) - and indeed 28 bytes larger due to IPv4 fragments. Thus removing the skb_decrease_gso_size() call doesn't actually increase the size of the packets your transmit side must be able to handle. ie. to handle non-GSO max-MTU packets, the IPv4/IPv6 device/ route MTUs must already be set correctly. Since for example with an IPv4 egress MTU of 1500, IPv4 to IPv6 translation will already build 1520 byte IPv6 frames, so you need a 1520 byte device MTU. This means if your IPv6 device's egress MTU is 1280, your IPv4 route must be 1260 (and actually 1252, because of the need to handle fragments). This is to handle normal non-GSO packets. Thus the reduction is simply not needed for GSO packets, because when they're correctly built, they will already be the right size. (f) TSO/GSO should be able to exactly undo GRO: the number of packets (TCP segments) should not be modified, so that TCP's MSS counting works correctly (this matters for congestion control). If protocol conversion changes the gso_size, then the number of TCP segments may increase or decrease. Packet loss after protocol conversion can result in partial loss of MSS segments that the sender sent. How's the sending TCP stack going to react to receiving ACKs/SACKs in the middle of the segments it sent? (g) skb_{decrease,increase}_gso_size() are already no-ops for GSO_BY_FRAGS case (besides triggering WARN_ON_ONCE). This means you already cannot guarantee that gso_size (and thus resulting packet MTU) is changed. ie. you must assume it won't be changed. (h) changing gso_size is outright buggy for UDP GSO packets, where framing matters (I believe that's also the case for SCTP, but it's already excluded by [g]). So the only remaining case is TCP, which also doesn't want it (see [f]). (i) see also the reasoning on the previous attempt at fixing this (commit fa7b83bf3b156c767f3e4a25bbf3817b08f3ff8e) which shows that the current behaviour causes TCP packet loss: In the forwarding path GRO -> BPF 6 to 4 -> GSO for TCP traffic, the coalesced packet payload can be > MSS, but < MSS + 20. bpf_skb_proto_6_to_4() will upgrade the MSS and it can be > the payload length. After then tcp_gso_segment checks for the payload length if it is <= MSS. The condition is causing the packet to be dropped. tcp_gso_segment(): [...] mss = skb_shinfo(skb)->gso_size; if (unlikely(skb->len <= mss)) goto out; [...] Thus changing the gso_size is simply a very bad idea. Increasing is unnecessary and buggy, and decreasing can go negative. Fixes: `6578171a7f` ("bpf: add bpf_skb_change_proto helper") Signed-off-by: Maciej Żenczykowski <maze@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Dongseok Yi <dseok.yi@samsung.com> Cc: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/bpf/CANP3RGfjLikQ6dg=YpBU0OeHvyv7JOki7CyOUS9modaXAi-9vQ@mail.gmail.com Link: https://lore.kernel.org/bpf/20210617000953.2787453-2-zenczykowski@gmail.com (cherry picked from commit 364745fbe981a4370f50274475da4675661104df https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=364745fbe981a4370f50274475da4675661104df ) Test: builds, TreeHugger Bug: 188690383 Signed-off-by: Maciej Żenczykowski <maze@google.com> Change-Id: I0ef3174cbd3caaa42d5779334a9c0bfdc9ab81f5		11 months ago
Documentation	sm7125: A525FXXS4CVK4	2 years ago
arch	sm7125: dts: get rid of in-kernel vendor mounting	1 year ago
block	A525FXXU4CVJB	2 years ago
certs	Import A525FXXU3AUG4	3 years ago
crypto	Import A525FXXU3AUG4	3 years ago
drivers	soc: memshare: Fix a implicit-int compilation error from clang 15.0.2	11 months ago
firmware	A525FXXU4CVJB	2 years ago
fs	A525FXXU4CVJB	2 years ago
include	bpf: Fix leakage of uninitialized bpf stack under speculation	11 months ago
init	Import A525FXXU3AUG4	3 years ago
ipc	Import A525FXXU3AUG4	3 years ago
kernel	bpf: No need to simulate speculative domain for immediates	11 months ago
lib	A525FXXU4CVJB	2 years ago
mm	mm: Fix a -Werror=strict-prototypes compilation error from clang 15	11 months ago
net	FROMGIT: bpf: Do not change gso_size during bpf_skb_change_proto()	11 months ago
samples	samples: bpf: Fix lwt_len_hist reusing previous BPF map	11 months ago
scripts	sm7125: A525FXXS4CVK4	2 years ago
security	A525FXXU4CVJB	2 years ago
sound	A525FXXU4CVJB	2 years ago
techpack	A525FXXU4CVJB	2 years ago
tools	selftests/bpf: make 'dubious pointer arithmetic' test useful	11 months ago
usr	Import A525FXXU3AUG4	3 years ago
virt	Import A525FXXU3AUG4	3 years ago
.cocciconfig	…
.get_maintainer.ignore	…
.gitattributes	.gitattributes: set git diff driver for C source code files	8 years ago
.gitignore	sm7125: Don't ignore .bin firmware files	3 years ago
.mailmap	.mailmap: Add Maciej W. Rozycki's Imagination e-mail address	7 years ago
Android.mk	Android: Add empty Android.mk file	2 years ago
AndroidKernel.mk	Import A525FXXU3AUG4	3 years ago
Androidbp	Import A525FXXU3AUG4	3 years ago
COPYING	Import A525FXXU3AUG4	3 years ago
CREDITS	Import A525FXXU3AUG4	3 years ago
Kbuild	Import A525FXXU3AUG4	3 years ago
Kconfig	Import A525FXXU3AUG4	3 years ago
MAINTAINERS	Import A525FXXU3AUG4	3 years ago
Makefile	Makefile: Move -Wno-unused-but-set-variable out of GCC only block	2 years ago
README	Import A525FXXU3AUG4	3 years ago
build.config.aarch64	Import A525FXXU3AUG4	3 years ago
build.config.common	Import A525FXXU3AUG4	3 years ago
build.config.cuttlefish.aarch64	Import A525FXXU3AUG4	3 years ago
build.config.cuttlefish.x86_64	Import A525FXXU3AUG4	3 years ago
build.config.goldfish.arm	Import A525FXXU3AUG4	3 years ago
build.config.goldfish.arm64	Import A525FXXU3AUG4	3 years ago
build.config.goldfish.mips	Import A525FXXU3AUG4	3 years ago
build.config.goldfish.mips64	Import A525FXXU3AUG4	3 years ago
build.config.goldfish.x86	Import A525FXXU3AUG4	3 years ago
build.config.goldfish.x86_64	Import A525FXXU3AUG4	3 years ago
build.config.x86_64	Import A525FXXU3AUG4	3 years ago
disable_dbgfs.sh	AndroidKernel: Disable debugfs for user builds	4 years ago
gen_headers_arm.bp	Import A525FXXU3AUG4	3 years ago
gen_headers_arm64.bp	Import A525FXXU3AUG4	3 years ago
kernel_headers.py	Import A525FXXU3AUG4	3 years ago
verity_dev_keys.x509	Import A525FXXU3AUG4	3 years ago

README

Linux kernel
============

This file was moved to Documentation/admin-guide/README.rst

Please notice that there are several guides for kernel developers and users.
These guides can be rendered in a number of formats, like HTML and PDF.

In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.

There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
See Documentation/00-INDEX for a list of what is contained in each file.

Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.