Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4971976yba; Tue, 30 Apr 2019 07:15:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqwQ7kiUq+XMxUV7tB44dWJa6MfBP8gm4N3ptpSZv0wqRwd/nVzprPA5RejwANM+JD9Oe7CG X-Received: by 2002:a65:65c9:: with SMTP id y9mr66561770pgv.47.1556633700497; Tue, 30 Apr 2019 07:15:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556633700; cv=none; d=google.com; s=arc-20160816; b=l2rK8VRw3VCJwdXA4SKlKVktr76R3jN7soYdysIO+YtcXQSTAob94TuouSmBDTVZG2 tM5WZRP3xtUNe6vHAkWOkYD3kPIhsqgWgrRRRb/Vurkt5d0I/64FRUYpDke8g6rjFreb tC/Qh4OO7gz27Co2EzGt7YZlcdyz19zuGUITG8QurWnAUB+7WMteKDhQ4yxBfhI9Sw9R Gd3nZXW/YysuK5YDXDixU7udAZqrgxiQEOJSMii/bQgJaDdM7DUFK8y6fnIPBLouXX83 bVzzXjdHUDTDb4OSefoKb2VK0KKGeyPXTh2w9wF/X1WUiN0huWAlLRHQv8BJzZDV8mI4 YY1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=ioYmj00qgnmuWkI3Cq5DutpBKe1yYIu4a0cplOH4Msw=; b=SqU3SUr8j7h2rv3UymNplWp1VbkO05U1XYOpkHj+aullsCOM0vxtnOnaZqq5rO52c7 nHDPuXlTCng3ad3j/BroCL5o9Tl1EXSxxzovBoa3B3Nq2eFR2kxG9ouEZ1EdyH7eOkC9 MuouqQ0BKQOUNOchhn4oXWVN9HCTDA2YV6enaRsf6REhsY3iMRVXiEZDxdfIZXJbYgyV xVeZCb5jxacFvHTqd75z1epPoKC51ziOUDjd1CJLfTuGOXEmX8AVNU4sUwKB5S11wPTO BSp5s8tjOsTrpyUEpR8Lxh8a5CHqbp697r5btaW694whrsvAkJZpR5ZWt1N1iBlZvcko Eopw== 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 z21si8604786plo.238.2019.04.30.07.14.41; Tue, 30 Apr 2019 07:15:00 -0700 (PDT) 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 S1727251AbfD3ONk (ORCPT + 99 others); Tue, 30 Apr 2019 10:13:40 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:35354 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726294AbfD3ONj (ORCPT ); Tue, 30 Apr 2019 10:13:39 -0400 Received: (qmail 1597 invoked by uid 2102); 30 Apr 2019 10:13:38 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Apr 2019 10:13:38 -0400 Date: Tue, 30 Apr 2019 10:13:38 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Eric Biggers cc: syzbot , , , , , , Subject: Re: KASAN: slab-out-of-bounds Read in hex_string In-Reply-To: <20190429210917.GA251866@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Apr 2019, Eric Biggers wrote: > On Mon, Apr 29, 2019 at 04:07:04PM -0400, Alan Stern wrote: > > Accessing beyond the end of the descriptor. > > > > #syz test: https://github.com/google/kasan.git usb-fuzzer > > > > --- a/drivers/video/fbdev/udlfb.c > > +++ b/drivers/video/fbdev/udlfb.c > > @@ -1511,6 +1511,7 @@ static int dlfb_parse_vendor_descriptor( > > char *buf; > > char *desc_end; > > int total_len; > > + int width; > > > > buf = kzalloc(MAX_VENDOR_DESCRIPTOR_SIZE, GFP_KERNEL); > > if (!buf) > > @@ -1529,9 +1530,10 @@ static int dlfb_parse_vendor_descriptor( > > } > > > > if (total_len > 5) { > > + width = min(total_len, 11); > > dev_info(&intf->dev, > > - "vendor descriptor length: %d data: %11ph\n", > > - total_len, desc); > > + "vendor descriptor length: %d data: %*ph\n", > > + total_len, width, desc); > > > > if ((desc[0] != total_len) || /* descriptor length */ > > (desc[1] != 0x5f) || /* vendor descriptor type */ > > > > > > Why not write just: > > dev_info(&intf->dev, > "vendor descriptor length: %d data: %*ph\n", > total_len, min(total_len, 11), desc); I did consider doing that. In the end I decided adding an extra temporary variable made the code a little more readable. (For some reason, extra recursion -- a function call embedded in a function argument -- seems to demand more mental effort than an extra temporary. Maybe my brain is just getting old...) > Also, aren't there more out-of-bounds reads in the code just after? It only > checks for at least 1 byte available, but then it reads up to 7 bytes: > > while (desc < desc_end) { > u8 length; > u16 key; > > key = *desc++; > key |= (u16)*desc++ << 8; > length = *desc++; > > switch (key) { > case 0x0200: { /* max_area */ > u32 max_area = *desc++; > max_area |= (u32)*desc++ << 8; > max_area |= (u32)*desc++ << 16; > max_area |= (u32)*desc++ << 24; > dev_warn(&intf->dev, > "DL chip limited to %d pixel modes\n", > max_area); > dlfb->sku_pixel_limit = max_area; > break; > } > default: > break; > } > desc += length; > } Quite right. Please feel free to submit a patch fixing all these problems. > Also I couldn't help but notice it's also using 'char' rather than 'u8', > so bytes >= 0x80 are read incorrectly as they're sign extended... As I recall, the C standard doesn't specify whether char is signed or unsigned; it can vary with the implementation. However you are certainly correct that to ensure there is no sign extension, the code should use unsigned char or u8. Alan Stern