netdev - [PATCH 0/4] usbnet: avoiding access auto-suspended device

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-next>] [day] [month] [year] [list]

Date:	Mon, 29 Oct 2012 15:45:05 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Oliver Neukum <oneukum@...e.de>, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org
Subject: [PATCH 0/4] usbnet: avoiding access auto-suspended device

Thip patchset avoids accessing auto-suspended device in ioctl path,
which is generally triggered by some network utility(ethtool, ifconfig,
...)

Most of network devices have the problem, but as discussed in the
thread:

	http://marc.info/?t=135054860600003&r=1&w=2

the problem should be solved inside driver.

Considered that only smsc75xx and smsc95xx calls usbnet_read_cmd()
and usbnet_write_cmd() inside its resume and suspend callback, the
patcheset introduce the nopm version of the two functions which
should be called only in the resume and suspend callback. So we
can solve the problem by runtime resuming device before doing
control message things.

The patchset is against 3.7.0-rc3-next-20121029, and has been tested
OK on smsc95xx usbnet device.

 drivers/net/usb/smsc75xx.c |  133 +++++++++++++++++++++++++++-----------------
 drivers/net/usb/smsc95xx.c |  122 ++++++++++++++++++++++++++--------------
 drivers/net/usb/usbnet.c   |   72 ++++++++++++++++++++++--
 include/linux/usb/usbnet.h |    4 ++
 4 files changed, 233 insertions(+), 98 deletions(-)

Thanks,
--
Ming Lei

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html