On Mon, Aug 05, 2024 at 04:33:39PM +0800, LidongLI wrote: > > Dear Greg, > > Thank you for your response and for considering the details I've provided so far. I would like to offer further clarification on the vulnerability and why it warrants assigning a CVE. > > ### Detailed Description of Vulnerability > > 1. **Root Cause and Exploitability**: > - The vulnerability in question can be triggered by sending specific data packets to a device driver, causing a Null Pointer Dereference in the kernel. This results in a complete system crash and reboot. Are you sure it's the sending random data and not the reset that is causing this? You also are attempting to send confused data while the driver is binding, so of course it is going to get confused, how could it not? > - While initially it appears to require root privileges, altering the Udev rules allows for exploiting this vulnerability from a non-root user space, significantly lowering the barrier for potential exploitation. Exactly what udev rule changes are required? And as that requires root permission, that is not really that big of an issue, right? > 2. **Impact on Systems**: > - The root cause is a race condition between the userspace resetting the device and the kernel driver initializing it. This is not an edge case but a common scenario that could occur in systems where devices are frequently reset or reinitialized. > - By manipulating Udev rules, an attacker can create a persistent and repeatable method to exploit the vulnerability, leading to Denial of Service (DoS) conditions. This can be particularly disruptive in production environments, impacting servers, IoT devices, and embedded systems relying on Ubuntu. If you can change udev rules, you own the machine, this is not a kernel issue. Again, there is a reason why normal users can't do this. > 3. **Practical Implications**: > - The fact that this can be achieved through Udev rules modification is significant because it demonstrates a path to escalate privileges and attack vectors that can be exploited in real-world scenarios. > - Systems that are exposed to user-space applications needing device resets or control operations could be particularly vulnerable, especially in multi-user environments. > > ### Experimental Evidence > ### Setting Up Udev Rules: Granting Permissions to Your USB Device Without Using sudo > > To grant permissions to your USB device without using `sudo`, you need to create a udev rules file. Follow these steps: > > #### Create the Udev Rules File: > > 1. Open a terminal and create the udev rules file with the following command: > > > sudo nano /etc/udev/rules.d/99-usb.rules > > > 2. Add the rule: In the file, add the following content. Replace `YOUR_VENDOR_ID` and `YOUR_PRODUCT_ID` with your device's vendor ID and product ID. > > > SUBSYSTEM=="usb", ATTR{idVendor}=="148f", ATTR{idProduct}=="3070", MODE="0666" So you are allowing any user to read/write to the device at the same time the driver is bound to it, but again, you had to be root to allow this to happen. So unless a normal user can do this, with the default permissions, this is just going to be a normal "fix up the usb driver to allow confused data to not confuse it" which is a normal thing. USB drivers were never originally designed to allow for malicious devices. We have slowly changed this over time to allow for semi-malicious USB configuration data to be handled properly, but we have not said "USB devices are not fully trusted" yet. If we want to do that, we need to do a lot of work as that is not how Linux (or really any operating system) is designed at the moment. Again, we will be glad to fix up the individual bugs here as found, but it's not a major issue as it's just something that someone with root permissions can do to a machine, along with thousands of worse things :) thanks, greg k-h