From nobody Thu Sep 18 06:43:54 2025 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:a05:6a06:869:b0:4b8:7781:bd2f with SMTP id d41csp2396038pis; Fri, 29 Apr 2022 08:52:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx67CDoFZsOLhivH4mQ9NMzDEDhc2mlEsBij2ugfCcLjjcyHxNqejAQs2nzQfIqSgr5sbBe X-Received: by 2002:a54:4119:0:b0:325:a6dc:efae with SMTP id l25-20020a544119000000b00325a6dcefaemr1725563oic.100.1651247556459; Fri, 29 Apr 2022 08:52:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651247556; cv=none; d=google.com; s=arc-20160816; b=zZxqE4TGT2CPmua0jcjAI4ve8US3oes3R9+MdhJ8/7/GQHbP7gi5cn+A9bN6xS3x79 e8H/ttnWOWv0TkhydHzd8Jk5wMtzGAOXgjBoAWUf41OVx69vNIjflHEUUn6UKzGdJuxv eqLOp31jbiio3H5U/0OAjlSyUIztCZa2XvQVxv0Gp9qX1PK9ri36+5ts0/6kzIIozOnT Y9Oxf6e5++D05ykeph9ZlCSlznW+kno7WrDEv7eDLr1oqgNJseIAzSe/sdUxq58QkcOd ZE0Xk4Zc1xggzicfxov3eW3S6onN3qN2ooZwaqE90qQeBc4NgB6rii/E6iFB7hpMV6yp kHEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:to:from :dkim-signature; bh=d0EYtuplUKATUj+pDa3zzZxtvw/RDBedsgt0bpG+Bxg=; b=WgKOWNBtC9dSs9qrotqQpQ+v1Atu+107NL0WBwNunkXZmDPLsQd4G7erd87u+Ewkbb A1GIBUbFEBdFBw2B5qGYEuVozAbcmPuUNuKJwjPRe65G0S+XCcMUBz/iGS6pW8mZd5F2 7DlPthqhDWlwclpXN4GyRPkZS7jAdt3w20mw38hjsO2f02vidJHM0EYP7aZ4L0D3ZJkM CRpu4SjmdaELUwt2UWKbHdEJuF3Z4nNp6b1lGG0kvK0TC6nnUHgHBAS9iZIv4j3TEPmS CMa8KHpo0/Z9nlyaLPvUXUuGQ+/ibtOIp16tbqS4JmBvC2xAgFa92FJac0dgsVT+0WND pc3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FQiBqmc+; spf=pass (google.com: domain of mptcp+bounces-4966-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:4040:4f00::1 as permitted sender) smtp.mailfrom="mptcp+bounces-4966-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from da.mirrors.kernel.org (da.mirrors.kernel.org. [2604:1380:4040:4f00::1]) by mx.google.com with ESMTPS id t4-20020acaaa04000000b003225ceaa6easi4185151oie.70.2022.04.29.08.52.36 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Apr 2022 08:52:36 -0700 (PDT) Received-SPF: pass (google.com: domain of mptcp+bounces-4966-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:4040:4f00::1 as permitted sender) client-ip=2604:1380:4040:4f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FQiBqmc+; spf=pass (google.com: domain of mptcp+bounces-4966-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:4040:4f00::1 as permitted sender) smtp.mailfrom="mptcp+bounces-4966-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by da.mirrors.kernel.org (Postfix) with ESMTPS id E2BE32E09B7 for ; Fri, 29 Apr 2022 15:52:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7AA711859; Fri, 29 Apr 2022 15:52:34 +0000 (UTC) X-Original-To: mptcp@lists.linux.dev Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D66A91852 for ; Fri, 29 Apr 2022 15:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651247551; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=d0EYtuplUKATUj+pDa3zzZxtvw/RDBedsgt0bpG+Bxg=; b=FQiBqmc+/htmlvO8RebGZqu684Ag0s1fhjRtMb05qZPm6dqEwN+2xdR80F5VbT8c63JJe9 6aoUeRP206pgE782NyxVLZQJJiV5opqPh6SGsPHOlc2DcKNG8G0Cn2Itoubwcz/QxT0Qh8 8cF3MKl0gM2DkyczAVxXULmTIm2CFbA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-231-3RlPp5gKPEaKTKvgnu8bBQ-1; Fri, 29 Apr 2022 11:52:30 -0400 X-MC-Unique: 3RlPp5gKPEaKTKvgnu8bBQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C2F9A3C0E198 for ; Fri, 29 Apr 2022 15:52:29 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.39.193.69]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4EBD6469A52 for ; Fri, 29 Apr 2022 15:52:29 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH mptcp-net] net/sched: act_pedit: really ensure the skb is writable Date: Fri, 29 Apr 2022 17:52:22 +0200 Message-Id: Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pabeni@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; x-default="true" Currently pedit tries to ensure that the accessed skb offset is writeble via skb_unclone(). The action potentially allows touching any skb bytes, so it may end-up modifying shared data. The above causes some sporadic MPTCP self-test failures. Address the issue keeping track of the (estimated) highest skb offset accessed by the action and ensure such offset is really writable. Note that this may cause performance regressions in some scenario, but hopefully pedit is not critical path. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Paolo Abeni --- this almost solves issues/265 here. I'm still getting some rare failure with MPTcpExtMPFailTx=3D=3D0: sometimes the transfer completes before we are able to use the 2nd/failing link. The relevant fix is a purely seft-test one --- include/net/tc_act/tc_pedit.h | 1 + net/sched/act_pedit.c | 14 ++++++++++++-- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/include/net/tc_act/tc_pedit.h b/include/net/tc_act/tc_pedit.h index 748cf87a4d7e..3e02709a1df6 100644 --- a/include/net/tc_act/tc_pedit.h +++ b/include/net/tc_act/tc_pedit.h @@ -14,6 +14,7 @@ struct tcf_pedit { struct tc_action common; unsigned char tcfp_nkeys; unsigned char tcfp_flags; + u32 tcfp_off_max_hint; struct tc_pedit_key *tcfp_keys; struct tcf_pedit_key_ex *tcfp_keys_ex; }; diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c index e01ef7f109f4..5ff37da2f9c3 100644 --- a/net/sched/act_pedit.c +++ b/net/sched/act_pedit.c @@ -149,7 +149,7 @@ static int tcf_pedit_init(struct net *net, struct nlatt= r *nla, struct nlattr *pattr; struct tcf_pedit *p; int ret =3D 0, err; - int ksize; + int i, ksize; u32 index; =20 if (!nla) { @@ -228,6 +228,16 @@ static int tcf_pedit_init(struct net *net, struct nlat= tr *nla, p->tcfp_nkeys =3D parm->nkeys; } memcpy(p->tcfp_keys, parm->keys, ksize); + p->tcfp_off_max_hint =3D 0; + for (i =3D 0; i < p->tcfp_nkeys; ++i) { + u32 cur; + + /* AT reads a single byte, we can bound the offset with UCHAR_MAX, + * each key will touch 4 bytes + */ + cur =3D p->tcfp_keys[i].off + p->tcfp_keys[i].offmask ? UCHAR_MAX >> p->= tcfp_keys[i].shift: 0; + p->tcfp_off_max_hint =3D max(p->tcfp_off_max_hint, cur + 4); + } =20 p->tcfp_flags =3D parm->flags; goto_ch =3D tcf_action_set_ctrlact(*a, parm->action, goto_ch); @@ -310,7 +320,7 @@ static int tcf_pedit_act(struct sk_buff *skb, const str= uct tc_action *a, struct tcf_pedit *p =3D to_pedit(a); int i; =20 - if (skb_unclone(skb, GFP_ATOMIC)) + if (skb_ensure_writable(skb, min(skb->len, p->tcfp_off_max_hint))) return p->tcf_action; =20 spin_lock(&p->tcf_lock); --=20 2.35.1