Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3088145ybb; Sun, 22 Mar 2020 15:13:35 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsKFbFscQw47e4qH28CSxb3jFhd9NXFh8RNoTMXKJe+k+d/j3UwMcmn9Tytxfj5tpEo9uFp X-Received: by 2002:a54:4001:: with SMTP id x1mr15476647oie.67.1584915215871; Sun, 22 Mar 2020 15:13:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584915215; cv=none; d=google.com; s=arc-20160816; b=y0VDfHmRyls3dnK1DUXMASdsWWlnHswhH5q3HX/N7xvjijVtGpB03gAOLplJE4k4lC O5U5DdbZkBE1on4sN07LxaXKvM+MQeGOkf9X5AIq1vjlnct8S+2JsL8MfMSyW5omxiLF SO/HBY8UUpNr0qaZhVygvOS8XEqdr18APGN73bD4I3R+w3Q0AofmJ4Xbvfv1v2aRNqgx HlG5xv/RndXgPfmcsiJFpU1CZ3Kl1N9JBK3L1mEGlB4hRwg9/STLEJQz6aD8NUmEUs5I fqxKsyEfonpntBU0b3g0OrDD2rf7DOX8uHdxPBv4Laqvf/oL93QjZnqeUioA6zvs9W3l hGMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=yY0NonJixEBJATXcD9oLEah6LRD98Gng9TgBDKslMqE=; b=tybTQ1OLH+EQ9hHEYCBImiDuKCIxNSMwxmcbVKFFlougzeCCOjmOvjFOlFfL9eWD6l DNGC99UFvEKDEWzkFw+8SRXlytDvFuSAhUcKpVKLLHROBoD4rLSgb72i2PfQoo7CDK5s EUH/QurPgIOFsiY/JGwlWLPztcXipAfILK2WmskiEQRdV0f4rD+rvietv5vgom9jJhUR IodQ/UKD7mxdKE0jXKK8mDAz6NuKW/jL9WjuN3LDlLLYnzqtZcMRukEdjQiCn1tj6wyu VfaFDkqRy8bHJTm5AHWZx4bS4bPFdQTPtsPVLzqWDgnBQZofnADR+sHWJ5SUvmVblb7C +DHQ== 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 d8si7205036oti.306.2020.03.22.15.13.23; Sun, 22 Mar 2020 15:13:35 -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 S1726958AbgCVWLK (ORCPT + 99 others); Sun, 22 Mar 2020 18:11:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:35488 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726809AbgCVWLJ (ORCPT ); Sun, 22 Mar 2020 18:11:09 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 9A575AFC1; Sun, 22 Mar 2020 22:11:07 +0000 (UTC) Date: Sun, 22 Mar 2020 23:11:06 +0100 From: Jean Delvare To: Dan Carpenter Cc: Daniel Kurtz , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot Subject: Re: [PATCH] i2c: i801: Fix memory corruption in i801_isr_byte_done() Message-ID: <20200322231106.3d431ced@endymion> In-Reply-To: <20200114073406.qaq3hbrhtx76fkes@kili.mountain> References: <0000000000009586b2059c13c7e1@google.com> <20200114073406.qaq3hbrhtx76fkes@kili.mountain> Organization: SUSE Linux X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dan, On Tue, 14 Jan 2020 10:34:06 +0300, Dan Carpenter wrote: > Assigning "priv->data[-1] = priv->len;" obviously doesn't make sense. > What it does is it ends up corrupting the last byte of priv->len so > priv->len becomes a very high number. I don't follow you, sorry. "priv->data[-1] = priv->len" is writing to priv->data, not priv->len, so I can't see how this could corrupt priv->len; Yes, I see that len is right before data in struct i801_priv, however priv->data is a pointer, not an array inside the structure, it points outside the structure so whatever is done through that pointer can't affect the structure's content. As for priv->data[-1], in priv->data is defined as: priv->data = &data->block[1]; which means the pointer is 1 byte inside the actual block array, therefore priv->data[-1] albeit convoluted looks legal to me. > Reported-by: syzbot+ed71512d469895b5b34e@syzkaller.appspotmail.com > Fixes: d3ff6ce40031 ("i2c-i801: Enable IRQ for byte_by_byte transactions") > Signed-off-by: Dan Carpenter > --- > Untested. > > drivers/i2c/busses/i2c-i801.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c > index f5e69fe56532..420d8025901e 100644 > --- a/drivers/i2c/busses/i2c-i801.c > +++ b/drivers/i2c/busses/i2c-i801.c > @@ -584,7 +584,6 @@ static void i801_isr_byte_done(struct i801_priv *priv) > "SMBus block read size is %d\n", > priv->len); > } > - priv->data[-1] = priv->len; > } > > /* Read next byte */ Definitely not correct. The first byte of the block data array MUST be the size of the block read. Even if the code above does not do the right thing, removing the line will not help. Is it possible that kasan got this wrong due to the convoluted logic? It's late and I'll check again tomorrow morning but the code looks OK to me. -- Jean Delvare SUSE L3 Support