Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Fri, 15 Apr 2022 12:57:21 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Wang Cheng <wanngchenng@gmail.com>
Cc:     Larry.Finger@lwfinger.net, florian.c.schilhabel@googlemail.com,
        gregkh@linuxfoundation.org, linux-staging@lists.linux.dev,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: rtl8712: fix uninit-value "data" and "mac"
Message-ID: <20220415095721.GR3293@kadam>
References: <20220414141223.qwiznrwgjyywngfg@ppc.localdomain>
 <20220414154215.GL3293@kadam>
 <20220415094705.aibh3jr4wzhddmud@ppc.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220415094705.aibh3jr4wzhddmud@ppc.localdomain>
User-Agent: Mutt/1.9.4 (2018-02-28)
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?db+khoLGwIZjwkrJoSn4EDVQEFEZvg3ySuQwXABUD/V4Aelvb3s9/ESWruoY?=
 =?us-ascii?Q?SSjoAi0YNO8WTqoX4lxIvtPT+YcUOLhFzMERTiA0ns23dt5R2MEEc5GqUjQK?=
 =?us-ascii?Q?VdXR7sc4t1h+FKAjeU/a1YcD9gK6cckCDPefrzPTXAlDsZhoJE0r4cJWKxPG?=
 =?us-ascii?Q?BdxckILz2tJtCt6TWEGMG8S/FicMGOHlYhB15w7BzU873yAhWuQSLj4DJ65u?=
 =?us-ascii?Q?mPQp5KsR0KqVu57J833TJML36TLeU1HzRSrs0Q/uf9i31chrPIPr2GUHlgTP?=
 =?us-ascii?Q?1GI8FAT1qc6PBmpQJSecmMlG0pYR0TLx163Dcp3kSh5XNlj5MxpX6tvM8AvM?=
 =?us-ascii?Q?bGbd0r6h+0/iUK8Ae8R/K+yLwcaXdgKpFLU/3Fb2a1bM5QqXbQHWlTyMyr9S?=
 =?us-ascii?Q?JYncpG7IkEfnojnpC5HePYo+i+KEbeo0YKsOw9EJNoFBZ60AHNyIqHVCGqhQ?=
 =?us-ascii?Q?mCE7H3wlFajaFOCcB/SbLmwjbmEKiiUx6zF4qydWkWkyKnL9JXTYPH+XgSbs?=
 =?us-ascii?Q?SLGvbxjOvBWuuJg6IBYvxrt7PIENacOHs5iEaYMW6xRZtIiOFdXPWh5X8zbg?=
 =?us-ascii?Q?7Cg3SwCs8uRtGrbtTU/S1f4r4F4iBQxrapcnbjCD5jj18kck6TQElHIQN4k1?=
 =?us-ascii?Q?R/Cq5qrnZROCEQVFf4h+bY3a4iu6WO2+3+RBJxqzefy2Je8GZ7N91mcHq6yC?=
 =?us-ascii?Q?stgC/zvZZIMYSY/a43JqgXg1JsdDqucYb4/i27o9r+ruHMwDfwLWNexYbUhw?=
 =?us-ascii?Q?ZJvQXS+upVmooxWIvxTWac01SbolmjQbTo9YiplX9Kr+mNpVGL//6EsKsu1O?=
 =?us-ascii?Q?crSkbKu1N/GgwFDv2U63/zYaketjRqS17CCinBfI8CCfhtSDIxZZEkEzP2ku?=
 =?us-ascii?Q?tPmeYnH9MKl8SNYBe3Uf+m7GbwLzUcSxEOM7dkgvJQm3o4OoFPsYWyW/F6Ei?=
 =?us-ascii?Q?Qc+YYtIVN776vBoRUcwM/LDIRbwpVG0g0LXITyDWqIxKiRMUkZ9vXXVNrRKl?=
 =?us-ascii?Q?QFgOpKYHEsxYxTl4esQtw09ZEWi2o+0bW/gIKXaRK+k/Vkn50ht5iKkQQh+N?=
 =?us-ascii?Q?ib0al+wwYJWOpnMnLEIx62ypAKRZ2VWBszFZY1oGyeUZs4m/8xz6suGiXtgu?=
 =?us-ascii?Q?I7c/uqSXk3jgTzBytsGz4c/0T60N75vDmzE0boeSpHsPEff+7JATeQR6z2Z+?=
 =?us-ascii?Q?BkoNJRr/nfgIxGNytwAd7GxLH+P0aC4BAR0tMhk7G1XF9JWJ5qbuOZmNBZg+?=
 =?us-ascii?Q?NZeoCtFQUMiNjMXcqHO+ba5K8swAuvBRqS58c2Ok9PvyLHxiKo9qZtnWBNKw?=
 =?us-ascii?Q?ZbZhinvKgY32yYGrQlOyAjBT6BUPX6OHhOiS81uXE6qbcdzohiMVuoV7SAln?=
 =?us-ascii?Q?VsUvdzA413lp8WWFp4T5WrhByWmJfff+Fo1uMsmVOWfTr48Z6+EQ4IgtfVID?=
 =?us-ascii?Q?wGZwWTYdcHODOPAYe+H4KQk0Zowg9cUb4RUVCu7+z8rIvW4xbNwLbR0zQurJ?=
 =?us-ascii?Q?YeTNp0+qwl7BKNTPYxP0AXlueIEQlpXPWj8ZrRXlL7SKq1+wK6nQe0zg4O5z?=
 =?us-ascii?Q?U3DwTGUbGptq7OJHyKfzZFOSqrMaxxptNudRKS/M2MXAy3uyzJamviXyAnHi?=
 =?us-ascii?Q?Sdc6mFzGis81EaPpyF0K9RxexWWGM93SUIQGk4jO3hL/2VBTU6HN6ihrYm4w?=
 =?us-ascii?Q?wu0Z3CZzVJRhGyTaWy9V464bBhCdIXeAwJCDER5rwgL5BAJWD2fNJTe6nT+G?=
 =?us-ascii?Q?DoXpT5/29C6MWkt2pVlhRUPDc1thhmU=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 20dce9b7-4e4a-4d04-f757-08da1ec66216
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2365.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2022 09:57:42.9063
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bhHVBzv+isvF8s2wjwXfteUCe3pcF/WwncNWvMt6zT5+FtbApuR/BynF7ersYdhHLg/gSstvRQCRYk5hQouyxQmoy2LuDiuxQWlGNKi/+oU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB5418
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-04-15_01:2022-04-14,2022-04-15 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 mlxscore=0
 bulkscore=0 phishscore=0 spamscore=0 mlxlogscore=999 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2204150058
X-Proofpoint-ORIG-GUID: vI7iQ5URih91Tu-hiIeO4DaFocb44kRK
X-Proofpoint-GUID: vI7iQ5URih91Tu-hiIeO4DaFocb44kRK
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 15, 2022 at 05:47:05PM +0800, Wang Cheng wrote:
> Hi Dan, thx for your review.
> 
> On 22/04/14 06:42PM, Dan Carpenter wrote:
> > On Thu, Apr 14, 2022 at 10:12:23PM +0800, Wang Cheng wrote:
> > > Due to the case that "requesttype == 0x01 && status <= 0"
> > > isn't handled in r8712_usbctrl_vendorreq(),
> > > "data" (drivers/staging/rtl8712/usb_ops.c:32)
> > > will be returned without initialization.
> > > 
> > > When "tmpU1b" (drivers/staging/rtl8712/usb_intf.c:395)
> > > is 0, mac[6] (usb_intf.c:394) won't be initialized,
> > > which leads to accessing uninit-value on usb_intf.c:541.
> > 
> > These line numbers are sort of useless because everyone is on a
> > different git hash.
> 
> I will correct this.
> 
> >
> > > 
> > > Reported-and-tested-by: syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com
> > > Signed-off-by: Wang Cheng <wanngchenng@gmail.com>
> > > ---
> > >  drivers/staging/rtl8712/usb_intf.c      |  6 +++---
> > >  drivers/staging/rtl8712/usb_ops_linux.c | 14 ++++++++------
> > >  2 files changed, 11 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/staging/rtl8712/usb_intf.c b/drivers/staging/rtl8712/usb_intf.c
> > > index ee4c61f85a07..50dcd3ecb685 100644
> > > --- a/drivers/staging/rtl8712/usb_intf.c
> > > +++ b/drivers/staging/rtl8712/usb_intf.c
> > > @@ -538,13 +538,13 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf,
> > >  		} else {
> > >  			AutoloadFail = false;
> > >  		}
> > > -		if (((mac[0] == 0xff) && (mac[1] == 0xff) &&
> > > +		if ((!AutoloadFail) ||
> > > +		    ((mac[0] == 0xff) && (mac[1] == 0xff) &&
> > >  		     (mac[2] == 0xff) && (mac[3] == 0xff) &&
> > >  		     (mac[4] == 0xff) && (mac[5] == 0xff)) ||
> > >  		    ((mac[0] == 0x00) && (mac[1] == 0x00) &&
> > >  		     (mac[2] == 0x00) && (mac[3] == 0x00) &&
> > > -		     (mac[4] == 0x00) && (mac[5] == 0x00)) ||
> > > -		     (!AutoloadFail)) {
> > > +		     (mac[4] == 0x00) && (mac[5] == 0x00))) {
> > >  			mac[0] = 0x00;
> > >  			mac[1] = 0xe0;
> > >  			mac[2] = 0x4c;
> > 
> > This is a separate fix from the rest of the patch.  Send it by itself.
> 
> Ah, thought to send a patch series.
> 

Yes, please.  Send two patches.

> > 
> > 
> > > diff --git a/drivers/staging/rtl8712/usb_ops_linux.c b/drivers/staging/rtl8712/usb_ops_linux.c
> > > index f984a5ab2c6f..e321ca4453ca 100644
> > > --- a/drivers/staging/rtl8712/usb_ops_linux.c
> > > +++ b/drivers/staging/rtl8712/usb_ops_linux.c
> > > @@ -495,12 +495,14 @@ int r8712_usbctrl_vendorreq(struct intf_priv *pintfpriv, u8 request, u16 value,
> > >  	}
> > >  	status = usb_control_msg(udev, pipe, request, reqtype, value, index,
> > >  				 pIo_buf, len, 500);
> > > -	if (status > 0) {  /* Success this control transfer. */
> > > -		if (requesttype == 0x01) {
> > > -			/* For Control read transfer, we have to copy the read
> > > -			 * data from pIo_buf to pdata.
> > > -			 */
> > > -			memcpy(pdata, pIo_buf,  status);
> > > +	/* For Control read transfer, copy the read data from pIo_buf to pdata
> > > +	 * when control transfer success; otherwise init *pdata with 0.
> > > +	 */
> > > +	if (requesttype == 0x01) {
> > > +		if (status > 0)
> > > +			memcpy(pdata, pIo_buf, status);
> > > +		else
> > > +			*(u32 *)pdata = 0;
> > >  		}
> > 
> > This isn't really correct.  In many cases status is "len" is less than 4.
> > I'm slightly surprised that nothing complains about that as an
> > uninitialized access.  But then another problem is that "status" can be
> > less than "len".
> 
> Sorry, I should explain it clearly. If I did right, watching "status"
> with gdb while running syzkaller reproducer, "status" returns from
> usb_control_msg() is -71. In which case, *pdata won't be touched in
> r8712_usbctrl_vendorreq(). As a result, "data" in
> usb_read8()/usb_read16()/usb_read32() will be returned without
> initialization. I think that is why kmsan reports:
> Local variable data created at:
>  usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33
>  r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29

Yes.  I understood that.

> 
> > 
> > A better fix instead of setting pdata to zero would be to add error
> > checking in the callers and then change this code to use
> > usb_control_msg_send/recv().  Probably just initialize "data" in the
> > callers as well.
> 
> I tried something similar which also works fine, but I think this patch
> does't fix it at root.
> https://syzkaller.appspot.com/text?tag=Patch&x=15be2970f00000
> 

Ugh...  Sorry, I had not looked closely at usb_read8() and friends.
(This code is all so terrible).  Ideally they would have some way to
return errors.  Oh well.  Anyway, I guess do like this:

	status = r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index,
					 &data, len, requesttype);
	if (status < 0)
		return 0;
	return (u8)(le32_to_cpu(data) & 0x0ff);

But in r8712_usbctrl_vendorreq() you really need to make the other
changes I mentioned as well.  If you want to do it as a separate patch
that's fine too.

	if (status < 0)
		return status;
	if (status != len)
		return -EREMOTEIO;

	if (reqtype == 0x1)
		memcpy();

	return 0;

regards,
dan carpenter