From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933015AbcKNGoL convert rfc822-to-8bit (ORCPT ); Mon, 14 Nov 2016 01:44:11 -0500 Received: from rtits2.realtek.com ([211.75.126.72]:48660 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752492AbcKNGoG (ORCPT ); Mon, 14 Nov 2016 01:44:06 -0500 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.56 with qID uAE6hopA019282, This message is accepted by code: ctloc85258 From: Hayes Wang To: Francois Romieu CC: "netdev@vger.kernel.org" , nic_swsd , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , "mlord@pobox.com" Subject: RE: [PATCH net 2/2] r8152: rx descriptor check Thread-Topic: [PATCH net 2/2] r8152: rx descriptor check Thread-Index: AQHSO+t5Wscn8cAer0W3mKS4Fv3VhKDTK/2AgATZvTA= Date: Mon, 14 Nov 2016 06:43:50 +0000 Message-ID: <0835B3720019904CB8F7AA43166CEEB20104EAF8@RTITMBSV03.realtek.com.tw> References: <1394712342-15778-226-Taiwan-albertk@realtek.com> <1394712342-15778-228-Taiwan-albertk@realtek.com> <20161111121311.GA19673@electric-eye.fr.zoreil.com> In-Reply-To: <20161111121311.GA19673@electric-eye.fr.zoreil.com> Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.177.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Francois Romieu [mailto:romieu@fr.zoreil.com] > Sent: Friday, November 11, 2016 8:13 PM [...] > Invalid packet size corrupted receive descriptors in Realtek's device > reminds of CVE-2009-4537. Do you mean that the driver would get a packet exceed the size which is set to RxMaxSize? I check it with our hw engineers. They don't get any issue about RxMaxSize. And their test for RxMaxSize register is fine. > Is the silicium of both devices different enough to prevent the same > exploit to happen ? For this case, I don't think the device provide a invalid value for the receive descriptors. However, the driver sees a different value. That is why I say the memory is unbelievable. Best Regards, Hayes