linux-kernel - Re: [PATCH] USB/ISP1760: Fix for unaligned exceptions

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081119091853.GA26629@www.tglx.de>
Date:	Wed, 19 Nov 2008 10:18:53 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	"Hennerich, Michael" <Michael.Hennerich@...log.com>
Cc:	Bryan Wu <cooloney@...nel.org>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB/ISP1760: Fix for unaligned exceptions

* Hennerich, Michael | 2008-11-18 15:41:01 [-0000]:

>Sebastian,
Michael,

>It's not just that single spot.
>I've seen unaligned pointers with count > 3 coming from various drivers.
>
>Here just two examples:
>
>1) The generic Bluetooth USB driver: CONFIG_BT_HCIUSB  
>Bluez-utils: hcitool scan:
>
>priv_write_copy: src = 00efaa09, dst = 203c1200, len = 13
>
>Full trace attached.
The trace is missing the kernel stack isn't it?

>
>2) RTL8150 based USB Ethernet adapter: CONFIG_USB_RTL8150
>dhcpcd:
>
>priv_read_copy: src = 00ea4812, dst = 203d8000, len = 64
0x00ea4812 doesn't feel right. Unless I'm missing something, this is
comming from rtl8150_open() while it was calling set_registers() to set
the mac address. So I assume the buffer is the mac address. This is
hardly possible because the MAC address itself is 6 bytes long and the
accompanying control packet has 8 bytes while this comment says that the
transfer legth is 64bytes. And since this is a control message, we
should not receive any response from the device.
Anyway with with WirelesEXT & NETPOLL in 32bit mode the offset from
begin of netdev to the mac address is 0x013c bytes and should be fine
for 32bit access. So either the netdev struct isn't properly aligned or
this a different transfer.

>I wonder if it's only us (NOMMU) seeing these odd aligned buffers?

Not sure. The only problem I have with this patch is that you might
cover bugs in drivers and you don't notice it anymore since you choose
"voluntary" the slow path.

>-Michael

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/