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: <CANthSfb+t53BZSXGe2VUUuHRYzphuT=-3vJtCSoERF_WChUr-A@mail.gmail.com>
Date:	Tue, 7 Jan 2014 11:35:50 +0800
From:	沈光 <shenguang10@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb:hub set hub->change_bits when over-current happens

On Tue, Jan 7, 2014 at 10:40 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote:
>> set hub->change_bits when we plug in a device which causes
>> over-current condition, so that hub_events() will check it.
>
> Why?
>
> What does this solve?  Is this a bug with existing devices that needs to
> be backported to older kernels?
>
> thanks,
>
> greg k-h

This is something that we found when we are doing compliance test with xHCI.
If we enable CONFIG_USB_SUSPEND, and plug in a bad device which causes
over-current condition to the root port, the hub->change_bits will not
be set in current code in the function of hub_activate.
Then hub_events() will ignore this change, below is a code fragment of
hub_events()
                /* deal with port status changes */
                for (i = 1; i <= hub->descriptor->bNbrPorts; i++) {
                        if (test_bit(i, hub->busy_bits))
                                continue;
                        connect_change = test_bit(i, hub->change_bits);
                        wakeup_change = test_and_clear_bit(i, hub->wakeup_bits);
                        if (!test_and_clear_bit(i, hub->event_bits) &&
                                        !connect_change && !wakeup_change)
                                continue;

According to spec, software need to disable the port if there is an
over-current condition, while current code will not, since it will not
detect such condition.

but if we disable CONFIG_USB_SUSPEND, software can detect the
over-current condition. I am still checking the code to get the
reason.

-- 
Shen Guang
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ