Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4132320pxu; Mon, 21 Dec 2020 05:10:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJyPzy8Tacsx9lmXskrTI17JWFGiuvdluG2YXAJFu8FW+ZwIqaJzf2FT30Rt2vVGpPKFEaYe X-Received: by 2002:a50:84a9:: with SMTP id 38mr15676580edq.378.1608556216637; Mon, 21 Dec 2020 05:10:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608556216; cv=none; d=google.com; s=arc-20160816; b=cip9toRq96r+ryC7Ksaluw4Bf93YzytMmZvmfUOo9+rTNQLaqT8dE66PyKMyBc5/vt eVLqVEzRogCEs7E79fy7e9eshGOmD+vqsJ6YC5I7vn4w/27yIBE6lU6DPD8AnrLPbkyH UdvA57ul3MR76CbsZ/2AlqD+6kL191RMhytKKPHsLZyRHAszTImGBxPeqHwSFHkSx7CF P5CZ9hOdduzw/AUz1Tm3s9n75O4mfj21MRxUzI5+wcmiDErI2H6YURhvlbiDXUoocGCg KxqrFfG2RbFOeUoc3+rAY6qT/KCCUilxB+ZBELa00tAKVh9D+5GNX1iL251AnWRzoPQR O1hA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=mPkTbiUTpIMa74IVZpajoJ+bktdy8Mq0agpX5MZSjUE=; b=UF+cQYW0moFc3jktTUU6MJoyUa0/v4BKWrvWqVuD11Z9UDW+MhqjpvWKT5pEHP3BN+ MDxFAdGjcxclAh//ldZxXvxiuqup0LNBK5v6A4AgOzapQFLEeJELfhYLkUnCx7wQek2f kcBes32esX5tDOSuNIuDZoU+MlcVthUW7u3IhZVCgn0YUf7OoL0mXSoQOqDMvveGbAQ2 QaPVfmrFf2GDV3QJkMi7IYEhmzUFf0/isdoLt/b0yyaiMDwdnSoNWSRek4HIDS5/e+WY pkXRYwbtiKqnPZkI+sMHJNyixQDMYKfYxvY7PI4h/Ukb/jNwqEdoSo4+zym+2ky9r51m /OQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u26si8511190ejx.267.2020.12.21.05.09.53; Mon, 21 Dec 2020 05:10:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726709AbgLUNJ0 (ORCPT + 99 others); Mon, 21 Dec 2020 08:09:26 -0500 Received: from out30-44.freemail.mail.aliyun.com ([115.124.30.44]:43068 "EHLO out30-44.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725807AbgLUNJ0 (ORCPT ); Mon, 21 Dec 2020 08:09:26 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04420;MF=weichen.chen@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0UJJwcON_1608556101; Received: from localhost(mailfrom:weichen.chen@linux.alibaba.com fp:SMTPD_---0UJJwcON_1608556101) by smtp.aliyun-inc.com(127.0.0.1); Mon, 21 Dec 2020 21:08:41 +0800 From: weichenchen To: kuba@kernel.org Cc: splendidsky.cwc@alibaba-inc.com, yanxu.zw@alibaba-inc.com, weichenchen , "David S. Miller" , Hangbin Liu , David Ahern , Roopa Prabhu , Roman Mashak , Vasily Averin , Jeff Dike , Li RongQing , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] net: neighbor: fix a crash caused by mod zero Date: Mon, 21 Dec 2020 21:07:44 +0800 Message-Id: <20201221130754.12628-1-weichen.chen@linux.alibaba.com> X-Mailer: git-send-email 2.20.1 (Apple Git-117) In-Reply-To: <20201219102116.3cc0d74c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> References: <20201219102116.3cc0d74c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org pneigh_enqueue() tries to obtain a random delay by mod NEIGH_VAR(p, PROXY_DELAY). However, NEIGH_VAR(p, PROXY_DELAY) migth be zero at that point because someone could write zero to /proc/sys/net/ipv4/neigh/[device]/proxy_delay after the callers check it. This patch double-checks NEIGH_VAR(p, PROXY_DELAY) in pneigh_enqueue() to ensure not to take zero as modulus. Signed-off-by: weichenchen --- V2: - Use READ_ONCE() to prevent the complier from re-reading NEIGH_VAR(p, PROXY_DELAY). - Give a hint to the complier that delay <= 0 is unlikely to happen. Note: I don't think having the caller pass in the value is a good idea mainly because delay should be only decided by /proc/sys/net/ipv4/neigh/[device]/proxy_delay rather than the caller. --- net/core/neighbour.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 9500d28a43b0..7b03d3f129c0 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -1570,9 +1570,14 @@ void pneigh_enqueue(struct neigh_table *tbl, struct neigh_parms *p, struct sk_buff *skb) { unsigned long now = jiffies; + unsigned long sched_next; - unsigned long sched_next = now + (prandom_u32() % - NEIGH_VAR(p, PROXY_DELAY)); + int delay = READ_ONCE(NEIGH_VAR(p, PROXY_DELAY)); + + if (unlikely(delay <= 0)) + sched_next = now; + else + sched_next = now + (prandom_u32() % delay); if (tbl->proxy_queue.qlen > NEIGH_VAR(p, PROXY_QLEN)) { kfree_skb(skb); -- 2.20.1 (Apple Git-117)