From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA346168 for ; Sat, 15 Jan 2022 04:14:04 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id f13so4485708plg.0 for ; Fri, 14 Jan 2022 20:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mfIrzj6cPcGzWR/gN8R7LyeEpSY521Rk0SIcNjAgQwo=; b=D4zpVPRtkIQYIqolRPih/thQZjac99N1tHrhrQcT4NLSu6zjJXH4rmRWaNBUL6gGa0 2McD+Nc+1QM0Nu586VyP4uNHqGirwrAj4JTypaa/zSdMaac6wmocNYLr/pOUsC1KtWQw x/6LRvnryvaGPECwPHL7/hu/JGK/oBFCuipqQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mfIrzj6cPcGzWR/gN8R7LyeEpSY521Rk0SIcNjAgQwo=; b=FasAXKZSSWB7rb0WAitBmpvXoFYStQpLZ57PIo7KonTaft1M1H6OOO+r1VU927BmYV x+IpxKc9qwMoNDozWrpPNDxg9B+JYoJo/Pgez/4eZ9HKR1oVRvzGMev2QaNYzcIdB8A8 xFnfKL73oWubFJFMuh20kOzW80s27qUZO9jnPauYMH4jAZ8U/hzlDk8vzeEZQs6yc8pW QFtukIUMCZLT4/ovXsmcCzou3407o5nkOHxoSj5WVnEUUjVfBEVndUCz17HeoGv+u2tJ CLslGGei3BRWalalKyyigtQnV7j4fGAiac+JjQ+88f9RR7D0xP3t1TWS+aTnbzykgdUb cnHA== X-Gm-Message-State: AOAM531DxC3asqa+TODLBm/fx9jf/yMcVndzETOgzgaSCoCzEwwkquIc /mWaPFGVFVORG1vBsWdCRQ5xYw== X-Google-Smtp-Source: ABdhPJxUkgWJzQPhcFWbWuR/K659eJVHLeC9GLGXuxaI75I5X0fvvZfdu3tleS0bdLQyXvQPZxcrvg== X-Received: by 2002:a17:902:6bc7:b0:149:9004:ca04 with SMTP id m7-20020a1709026bc700b001499004ca04mr12535270plt.43.1642220044226; Fri, 14 Jan 2022 20:14:04 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id oj6sm9671328pjb.18.2022.01.14.20.14.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Jan 2022 20:14:03 -0800 (PST) Date: Fri, 14 Jan 2022 20:14:03 -0800 From: Kees Cook To: Greg Kroah-Hartman Cc: Larry Finger , Phillip Potter , Michael Straube , Fabio Aiuto , linux-staging@lists.linux.dev, Hans de Goede , Dan Carpenter , Marco Cesati , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] staging: rtl8723bs: Check for NULL header value Message-ID: <202201141958.5864A3ABD@keescook> References: <20220113002001.3498383-1-keescook@chromium.org> <202201131027.FCAC3072E4@keescook> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Jan 13, 2022 at 07:51:24PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 13, 2022 at 10:29:04AM -0800, Kees Cook wrote: > > On Thu, Jan 13, 2022 at 10:13:46AM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Jan 12, 2022 at 04:20:01PM -0800, Kees Cook wrote: > > > > When building with -Warray-bounds, the following warning is emitted: > > > > > > > > In file included from ./include/linux/string.h:253, > > > > from ./arch/x86/include/asm/page_32.h:22, > > > > from ./arch/x86/include/asm/page.h:14, > > > > from ./arch/x86/include/asm/thread_info.h:12, > > > > from ./include/linux/thread_info.h:60, > > > > from ./arch/x86/include/asm/preempt.h:7, > > > > from ./include/linux/preempt.h:78, > > > > from ./include/linux/rcupdate.h:27, > > > > from ./include/linux/rculist.h:11, > > > > from ./include/linux/sched/signal.h:5, > > > > from ./drivers/staging/rtl8723bs/include/drv_types.h:17, > > > > from drivers/staging/rtl8723bs/core/rtw_recv.c:7: > > > > In function 'memcpy', > > > > inlined from 'wlanhdr_to_ethhdr' at drivers/staging/rtl8723bs/core/rtw_recv.c:1554:2: > > > > ./include/linux/fortify-string.h:41:33: warning: '__builtin_memcpy' offset [0, 5] is out of the bounds [0, 0] [-Warray-bounds] > > > > 41 | #define __underlying_memcpy __builtin_memcpy > > > > | ^ > > > > > > > > This is because the compiler sees it is possible for "ptr" to be a NULL > > > > value, and concludes that it has zero size and attempts to copy to it > > > > would overflow. Instead, detect the NULL return and error out early. > > > > > > > > Cc: Larry Finger > > > > Cc: Phillip Potter > > > > Cc: Greg Kroah-Hartman > > > > Cc: Michael Straube > > > > Cc: Fabio Aiuto > > > > Cc: linux-staging@lists.linux.dev > > > > Signed-off-by: Kees Cook > > > > --- > > > > drivers/staging/rtl8723bs/core/rtw_recv.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c b/drivers/staging/rtl8723bs/core/rtw_recv.c > > > > index 41bfca549c64..61135c49322b 100644 > > > > --- a/drivers/staging/rtl8723bs/core/rtw_recv.c > > > > +++ b/drivers/staging/rtl8723bs/core/rtw_recv.c > > > > @@ -1513,6 +1513,9 @@ static signed int wlanhdr_to_ethhdr(union recv_frame *precvframe) > > > > u8 *ptr = get_recvframe_data(precvframe) ; /* point to frame_ctrl field */ > > > > struct rx_pkt_attrib *pattrib = &precvframe->u.hdr.attrib; > > > > > > > > + if (!ptr) > > > > + return _FAIL; > > > > > > This will never happen, so let's not paper over compiler issues with > > > stuff like this please. > > > > > > As the call to get_recvframe_data() is only done in one place in this > > > driver (in all drivers that look like this as well), it can just be > > > replaced with the real code instead of the nonsensical test for NULL and > > > then the compiler should be happy. > > > > > > I'll gladly take that fix instead of this one, as that would be the > > > correct solution here. > > > > I changed it around, but it doesn't help. I assume this is because we > > build with -fno-delete-null-pointer-checks, so the compiler continues > > to assume it's possible for the incoming argument to be NULL. > > That's a broken compiler then. > > > Should I rearrange this to do a NULL check for precvframe before all the > > assignments in addition to removing get_recvframe_data()? > > If you walk the call-chain back, you will see that precvframe can't ever > be NULL here (which is why this code doesn't crash), so don't check for > something that is impossible to ever hit please just because the > compiler is broken. I agree that the _original_ precvframe is always non-NULL, but the pointer landing at memcpy() gets updated along the way. It seems the new problem is that recvframe_pull() may return NULL and nothing is checking for that. Adding this silences the warning: diff --git a/drivers/staging/r8188eu/core/rtw_recv.c b/drivers/staging/r8188eu/core/rtw_recv.c index 49a02d6239d6..946e659ae97a 100644 --- a/drivers/staging/r8188eu/core/rtw_recv.c +++ b/drivers/staging/r8188eu/core/rtw_recv.c @@ -1223,10 +1223,14 @@ static int wlanhdr_to_ethhdr(struct recv_frame *precvframe) eth_type = 0x8712; /* append rx status for mp test packets */ ptr = recvframe_pull(precvframe, (rmv_len - sizeof(struct ethhdr) + 2) - 24); + if (!ptr) + return _FAIL; memcpy(ptr, get_rxmem(precvframe), 24); ptr += 24; } else { ptr = recvframe_pull(precvframe, (rmv_len - sizeof(struct ethhdr) + (bsnaphdr ? 2 : 0))); + if (!ptr) + return _FAIL; } memcpy(ptr, pattrib->dst, ETH_ALEN); > > thanks, > > greg k-h -- Kees Cook