lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 25 Nov 2016 06:51:19 +0000 From: Hayes Wang <hayeswang@...ltek.com> To: Mark Lord <mlord@...ox.com>, David Miller <davem@...emloft.net> CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, nic_swsd <nic_swsd@...ltek.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org> Subject: RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable > Mark Lord [mailto:mlord@...ox.com] > > Sent: Friday, November 25, 2016 12:44 AM > [...] > > The bad data in this case is ASCII: > > > > "SRC=m3400:/ TARGET=/m340" > > > > This data is what is seen in /run/mount/utab, a file that is read/written over NFS > on > > each boot. > > > > "SRC=m3400:/ TARGET=/m3400 ROOT=/ > > ATTRS=nolock,addr=192.168.8.1\n" > > > > But how does this ASCII data end up at offset zero of the rx buffer?? > > Not possible -- this isn't even stale data, because only an rx_desc could > > be at that offset in that buffer. > > > > So even if this were a platform memory coherency issue, one should still > > never see ASCII data at the beginning of an rx buffer. The driver NEVER > > writes anything to the rx buffers. Only the USB hardware ever does. > > > > And only the r8152 dongle/driver exhibits this issue. > > Other USB dongles do not. They *might* still have such issues, > > but because they use software checksums, the bad packets are caught/rejected. > > Do you test it by rebooting? Maybe you could try a patch > commit 93fe9b183840 ("r8152: reset the bmu"). However, it should > only occur for the first urb buffer after rx is reset. I don't > think you would reset the rx frequently, so the situation seems > to be different. Forgive me. I provide wrong information. This is about RTL8153, not RTL8152. Best Regards, Hayes
Powered by blists - more mailing lists