Received: by 10.223.185.116 with SMTP id b49csp6345447wrg; Wed, 28 Feb 2018 07:57:03 -0800 (PST) X-Google-Smtp-Source: AH8x224L3xksZtMSTnoBNjX0zqaU4Li1olnObTTOUvdd0OaoSF9kYNsUYkejHpw3YyRw1d8zaHDx X-Received: by 10.99.97.9 with SMTP id v9mr14441343pgb.373.1519833423452; Wed, 28 Feb 2018 07:57:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519833423; cv=none; d=google.com; s=arc-20160816; b=BkuZJzMQI/wCag+6IjYqFusXkG8IHRTKQKKuDdiT7/XesjcStmI9rJalUsXbRvfnr8 T2McMhyKIPPUn1NkwG3QzpOfWFvqQ+Cg3F1ENEcsXG2Mi+AXfNTlrJta/ehfVBVRz2CP eGGBBcG9Bqm8VMVE72DVoBbODZO51oNvrY3BWWDLCoZDz3jFoKsMBXwEdLUitj/qHpn3 MX9t1Qgt9YrT7F3X6M8aCKwCf/4Pnjp2DR2y+MwwPyDO+SEa4SZce5Aw+AzpwYgqdp6X J2Y2/DVOgq9rKRrf0HaeAa4ZwFtCKph4TWVFeRJeMnZypiMmX9znn6gR5d3U+cTQA+KO PjVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=KWG6p3qumO30HvKGLFILQbsEMIfC/gusQ9ysnqplXkU=; b=dc+peBplRTV8jq343u+c9RKwG1c0wTrt7qu0DbktaQvTFku17K2Wr1mibK5qfP109E v3xj9uPd/kMDSPViBHZG7g1RthU8dO8urgbgi51Bo6lF9qDdjNzz6686RhJkVpFWu7xB 1nlCjQam/S0d9YbtoPYNJLJMmrHvshJCyhJiQ9fF5UMUvRIOz7LBBos/0aqmb0W9bB35 zOk4wgNCOMq3H+V4JW2cU+wkHm26j8JGRw9+EsrI/eju1GANmxvEafPrnb1eVToFe2bb 06qc23g/yadXumsvzsBd/8Fp4rJcSyjYx0x19mdXRY1q9PW7BWBmVFNV8e85bzihZ33c spww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e13si1405741pff.8.2018.02.28.07.56.48; Wed, 28 Feb 2018 07:57:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934060AbeB1PzJ (ORCPT + 99 others); Wed, 28 Feb 2018 10:55:09 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34449 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933722AbeB1PxY (ORCPT ); Wed, 28 Feb 2018 10:53:24 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yq-0006XU-59; Wed, 28 Feb 2018 15:22:28 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yj-0000FI-H7; Wed, 28 Feb 2018 15:22:21 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "David S. Miller" , "Nicolai Stange" , "Stefano Brivio" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 195/254] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg() In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Nicolai Stange commit 20b50d79974ea3192e8c3ab7faf4e536e5f14d8f upstream. Commit 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling due to concurrent updates by reading this bit-field member into a local variable and using the thus stabilized value in subsequent tests. However, aforementioned commit also adds the (correct) comment that /* hdrincl should be READ_ONCE(inet->hdrincl) * but READ_ONCE() doesn't work with bit fields */ because as it stands, the compiler is free to shortcut or even eliminate the local variable at its will. Note that I have not seen anything like this happening in reality and thus, the concern is a theoretical one. However, in order to be on the safe side, emulate a READ_ONCE() on the bit-field by doing it on the local 'hdrincl' variable itself: int hdrincl = inet->hdrincl; hdrincl = READ_ONCE(hdrincl); This breaks the chain in the sense that the compiler is not allowed to replace subsequent reads from hdrincl with reloads from inet->hdrincl. Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg") Signed-off-by: Nicolai Stange Reviewed-by: Stefano Brivio Signed-off-by: David S. Miller [bwh: Backported to 3.16: use ACCESS_ONCE()] Signed-off-by: Ben Hutchings --- net/ipv4/raw.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/net/ipv4/raw.c +++ b/net/ipv4/raw.c @@ -497,9 +497,11 @@ static int raw_sendmsg(struct kiocb *ioc goto out; /* hdrincl should be READ_ONCE(inet->hdrincl) - * but READ_ONCE() doesn't work with bit fields + * but READ_ONCE() doesn't work with bit fields. + * Doing this indirectly yields the same result. */ hdrincl = inet->hdrincl; + hdrincl = ACCESS_ONCE(hdrincl); /* * Check the flags. */