Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Greg KH]

On Sat, Aug 03, 2024 at 12:03:26AM +0300, Kalle Valo wrote:
> Mark Esler <mark.esler@canonical.com> writes:
> 
> > On Fri, Aug 02, 2024 at 03:57:47PM +0800, color Ice wrote:
> >> Dear RT2X00 driver maintainers,
> >> 
> >> We have discovered a critical vulnerability in the RT2X00 driver. We
> >> recommend urgently submitting an update.
> >> 
> >> *Vulnerability Description*: When a PC is running Ubuntu 22.04 or 24.04,
> >> executing our proof of concept (POC) can directly cause a null pointer
> >> dereference or use-after-free (UAF). The systems we tested were:
> >> 
> >>    - *Description*: Ubuntu 22.04.4 LTS *Release*: 22.04
> >>    - *Description*: Ubuntu 24.04 LTS *Release*: 24.04
> >> 
> >> We tested network cards from the RT2870/RT3070/RT5370 series, which all
> >> belong to the RT2X00 driver group, and all were able to trigger the
> >> vulnerability. Additionally, executing the POC requires only user-level
> >> privileges. Debian systems are not affected.
> >
> > It is unclear if Ubuntu is the only affected distro.
> 
> It's also unclear how this works as there's no description about the
> issue. I'm not going to run any scripts and I don't know how python
> usb.core package works. I guess it needs root privileges to be able to
> send these USB commands?
> 
> If this really is a security vulnerability, here are the instructions
> how to report them:
> 
> https://docs.kernel.org/process/security-bugs.html

This is public now, so security@k.o doesn't matter anymore.  But it
should just be sent to the linux-usb mailing list, as this just looks
like "sending a USB random data causes problems."

But the odd thing is that you are sending data to a device that already
has a driver bound to it.  How is libusb allowing that to happen?
Shouldn't it require you to unbind the device from the driver first
before talking to it over usbfs?

thanks,

greg k-h

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[LidongLI]

Hi Greg,



Alright, if you have any issues, please feel free to contact us. We believe the issue might be caused by the time.sleep() function set during packet transmission. Please reproduce and investigate."

If you need any adjustments or further assistance, just let me know!




Best regards,

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[LidongLI]

Hi Greg,

We tried it, and after configuring the udev rules, I can run the proof of concept (PoC) and reproduce the previous issue without using sudo






Best regards,

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[LidongLI]

Hi Greg,

We tried it, and after configuring the udev rules, I can run the proof of concept (PoC) and reproduce the previous issue without using sudo






Best regards,

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Greg KH]

On Mon, Aug 05, 2024 at 10:20:30AM +0800, LidongLI wrote:
> Hi Greg,
> 
> We tried it, and after configuring the udev rules, I can run the proof of concept (PoC) and reproduce the previous issue without using sudo
> 

What did you do exactly with a new udev rule?  Did you give it userspace
permission to unbind/reset the device?

As it is today, this requires root permissions and it looks to just be a
race with the existing kernel driver setting the device up and userspace
trying to reset the device at the same time, not anything that can
normally happen in a system from what I can tell.

thanks,

greg k-h

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[LidongLI]

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.
    - 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.

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.

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"
  

#### Restart the udev Service:

3. To apply the new rule, restart the udev service with these commands:

 
   sudo udevadm control --reload-rules
   sudo udevadm trigger
  
Regarding the discussion on permission issues, I would like to further illustrate that it is very common and reasonable to configure similar udev rules to allow non-root users direct access to USB devices in many practical scenarios. Below are some specific examples:

Educational and Experimental Environments:
In university courses on computer networking or wireless networking experiments, students frequently need access to various USB wireless devices to complete their experiments. To simplify permission management and improve experimental efficiency, teachers or lab administrators often add udev rules allowing all students to conveniently access and operate these devices without using sudo privileges.

Development Environments:
In software development companies, developers often need to debug and develop network-related applications, such as network monitoring tools and WiFi management tools. Frequent use of sudo privileges reduces development efficiency, so development environments commonly configure udev rules to simplify permission management, enabling developers to directly access these USB devices.

Automated Testing Environments:
In automated testing labs, test scripts need frequent access to and configuration of USB wireless devices for performance testing or connection testing. To ensure test scripts can run unobstructed, testing engineers would add udev rules so that test scripts can run without sudo privileges.

Custom Devices for Specific Purposes:
In home automation or custom devices for specific purposes (e.g., homemade NAS or IoT devices), administrators want to ensure that certain USB devices (such as wireless adapters) are plug-and-play, and the system can automatically recognize and configure these devices. In such cases, configuring udev rules to open device usage permissions is very common.

Embedded Systems:
In embedded systems (such as routers or VPN devices), it may be necessary to configure USB wireless adapters to expand connectivity. These devices often have a set of default permission configurations to ensure that wireless adapters can be automatically recognized and used, avoiding manual permission settings each time.

Based on these various practical application scenarios, even though the system's default configuration might require sudo privileges, these real-world configuration needs are entirely reasonable and common. When devices use udev rules, non-root users can bypass the default permission restrictions, making race conditions a significant security vulnerability worth attention. To ensure system security and stability,


### Request for CVE Assignment

Given the above details, I believe this vulnerability has the following implications:
- **Denial of Service**: Potential for attackers to cause persistent reboots and disruptions in a variety of environments.
- **Privilege Escalation**: Demonstrates a pathway for non-root users to exploit kernel weaknesses by leveraging standard system configurations (such as Udev rules).

Assigning a CVE to this issue would help track and mitigate the impact across affected systems and emphasize the critical need for a patch or workaround.

Thank you for your consideration. I look forward to any further questions or clarifications needed.

Best regards,


### Tips for Strengthening Your Argument

1. **Provide Evidence**: Include logs, stack traces, or any crash reports that underscore the vulnerability's impact.
2. **Highlight Real-World Scenarios**: Describe how the vulnerability can be exploited in practical, real-world situations.
3. **Be Precise and Clear**: Use technical terminology appropriately and explain any assumptions or configurations required to trigger the vulnerability.
4. **Emphasize Risk**: Stress how easy it is for an attacker to achieve their goals once the Udev rule is modified, even if it's a non-default configuration.

Remember, the goal is to present the vulnerability convincingly as a security risk that needs to be tracked and addressed with a CVE assignment.

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Greg KH]

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

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Greg KH]

On Mon, Aug 05, 2024 at 04:33:39PM +0800, LidongLI wrote:
> ### Tips for Strengthening Your Argument
> 
> 1. **Provide Evidence**: Include logs, stack traces, or any crash reports that underscore the vulnerability's impact.
> 2. **Highlight Real-World Scenarios**: Describe how the vulnerability can be exploited in practical, real-world situations.
> 3. **Be Precise and Clear**: Use technical terminology appropriately and explain any assumptions or configurations required to trigger the vulnerability.
> 4. **Emphasize Risk**: Stress how easy it is for an attacker to achieve their goals once the Udev rule is modified, even if it's a non-default configuration.
> 
> Remember, the goal is to present the vulnerability convincingly as a security risk that needs to be tracked and addressed with a CVE assignment.

Note, please work with your professor who has assigned you this task to
not actually include the task assignment in the emails you send out.

This didn't help any :)

good luck on your grade!

greg k-h

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[LidongLI]

Dear Greg,

Thank you, Greg!


Yes, as you mentioned, it requires users to create their own udev rules, which is not common among Ubuntu personal users. However, in some non-personal user scenarios, they must pre-add udev rules to meet their needs. A simple example: in some Ubuntu embedded Linux scenarios, we found that when starting a wireless hotspot, developers must configure udev rules to ensure a stable connection, enable auto-loading of drivers, or auto-run or write USB-based auto-configuration scripts.

Alright, thank you for your fix. We will proceed to the email you specified to request a CVE.

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[LidongLI]

Dear Greg,


Here is a scenario where udev rules are necessary. They can be used to automatically execute a series of configuration and security operations when a wireless network adapter is inserted, ensuring the stability and security of the system. An example is as follows:





# 1. Create a udev rules file
sudo nano /etc/udev/rules.d/99-custom-usb.rules

# 2. Add the following content to the file, replacing idVendor and idProduct with actual values
SUBSYSTEM=="usb", ATTR{idVendor}=="148f", ATTR{idProduct}=="3070", MODE="0666", RUN+="/path/to/custom/script.sh"

# 3. Example of a custom script
# Create a script file
sudo nano /path/to/custom/script.sh

# Add custom commands to the script file
#!/bin/bash
# Example commands
iwconfig wlan0 essid "MyNetwork"
ifconfig wlan0 up
dhclient wlan0

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Theodore Ts'o]

On Tue, Aug 06, 2024 at 09:59:04AM +0800, LidongLI wrote:
> 
> Yes, as you mentioned, it requires users to create their own udev
> rules, which is not common among Ubuntu personal users. However, in
> some non-personal user scenarios, they must pre-add udev rules to
> meet their needs. A simple example: in some Ubuntu embedded Linux
> scenarios, we found that when starting a wireless hotspot,
> developers must configure udev rules to ensure a stable connection,
> enable auto-loading of drivers, or auto-run or write USB-based
> auto-configuration scripts.

Yes, but when the user is setting up their own udev rules, they are
editing them as root (e.g, "sudo nano /etc/udev/rules.d/").

But in your exploit scenario, the *attacker* needs to be able to
insert a specific udev rule to allow the attack to succeed.  So that
means that the attacker needs to be able to manipulate the user to
insert a udev rule which allows the attacker to acarry out the attack,
or the user has left the udev rule file in such a way that it is
writeable by the attacker.  But in that case, the attacker can just
edit the udev rule to arrange to run some script as root, ad it's
already game over.

Your argument is roughly the same as "sudo is a vulerability because
the attacker could run (or trick the user to run) the command 'sudo
chmod 4755 /bin/bash'.  Well yes, if the attacker can arrange to run a
particular command as root, it's game over.  But that's not a security
bug, but rather a bug in the gullible user who has root access.

Similarly, if the user has a insecure configuration --- say, suppose
the user has run the command "sudo chmod 4755 /bin/bash", it does not
follow that this is a reason to request a CVE for /bin/bash.  It's not
really a security bug in /bin/bash, but a bug in how /bin/bash was
confiured.

Cheers,

						- Ted

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[LidongLI]

Hi Ted,

Thank you for your detailed response.

An attacker doesn't need to create a udev rule in the user's path because that isn't feasible. We need to consider scenarios where certain special devices (embedded systems) are designed from the outset with RT2X00 wireless network cards included in the udev rules. This is because they need to perform custom or automated functions related to the embedded system's operations.

Therefore, what I want to emphasize is that while this vulnerability may not affect users who do not have udev rules configured, setting udev rules is not inherently insecure. It is a normal configuration. Without udev rules, USB devices cannot be properly invoked or perform additional functions under certain conditions. It's a necessary feature.

However, for users utilizing RT2X00 drivers with this normal configuration, it directly allows the execution of the script without sudo, leading to a system crash. This indicates that the RT2X00 driver itself has a vulnerability that needs to be addressed. A robust and secure kernel and driver should not crash or dereference a null pointer regardless of the script run or the permissions used. We tested other drivers and did not encounter similar issues.

I believe this issue should be considered from two aspects:

1.The vulnerability indeed requires certain conditions to be triggered, but the configuration required is normal and necessary.
2.Running the script does cause a kernel null pointer dereference. Any robust and secure system should not encounter null pointer dereferences or crashes.

I understand your analogy with the /bin/bash example, and I'd like to clarify a couple of points to provide more context for why I believe this should be considered a security issue:

Normal and Necessary Configuration: While it is true that setting up udev rules is not common among typical personal Ubuntu users, there are legitimate and necessary scenarios, especially in embedded Linux environments, where such configurations are required. For example, in industrial automation systems, USB devices are often used to connect various sensors and controllers. In such environments, udev rules are configured to automatically load specific drivers or execute scripts upon device connection to ensure the proper operation of the system. This setup is essential for the reliable functioning of the automation process and is not an example of an insecure configuration.

System Robustness and Stability: Regardless of the configuration, a robust and secure system should handle unexpected inputs gracefully. In this case, running the script under the specified conditions causes a kernel null pointer dereference, leading to a system crash. For instance, consider a medical device scenario where a USB-connected device is used for critical patient monitoring. The udev rule is set to load necessary drivers and start monitoring software automatically upon connection. If an attacker can exploit this setup to cause a kernel crash, it can lead to severe consequences, including potential harm to patients. This example highlights that the presence of udev rules is not inherently insecure; rather, the kernel's inability to handle the input correctly is the underlying issue.

These points underscore the importance of addressing this vulnerability. While the initial setup requires root permissions, the critical aspect is the kernel's handling of the input, which should be robust enough to prevent crashes or null pointer dereferences, ensuring the system's stability and security.


Our requirement is to assign a CVE for this "bug" because it is an issue within the kernel. Since it is a problem, it poses a potential risk. Therefore, we believe it is necessary to address it accordingly.

Because it involves a driver development error, we believe it is necessary and meaningful to address this issue.
Cheers,

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Greg KH]

On Tue, Aug 06, 2024 at 11:54:33AM +0800, LidongLI wrote:
> 
> Hi Ted,
> 
> Thank you for your detailed response.
> 
> An attacker doesn't need to create a udev rule in the user's path because that isn't feasible. We need to consider scenarios where certain special devices (embedded systems) are designed from the outset with RT2X00 wireless network cards included in the udev rules. This is because they need to perform custom or automated functions related to the embedded system's operations.
> 
> Therefore, what I want to emphasize is that while this vulnerability may not affect users who do not have udev rules configured, setting udev rules is not inherently insecure. It is a normal configuration. Without udev rules, USB devices cannot be properly invoked or perform additional functions under certain conditions. It's a necessary feature.
> 
> However, for users utilizing RT2X00 drivers with this normal configuration, it directly allows the execution of the script without sudo, leading to a system crash. This indicates that the RT2X00 driver itself has a vulnerability that needs to be addressed. A robust and secure kernel and driver should not crash or dereference a null pointer regardless of the script run or the permissions used. We tested other drivers and did not encounter similar issues.
> 
> I believe this issue should be considered from two aspects:
> 
> 1.The vulnerability indeed requires certain conditions to be triggered, but the configuration required is normal and necessary.

No, the configuration is not normal or necessary at all, there is no
such default udev rule, or system configuration that allows what you
have found to be triggered by a normal user without root permissions.

If you think there is a bug in the kernel here, wonderful, please submit
a kernel patch to resolve the issue and we will be glad to review it.

I don't have time to look into this until next week due to travel, so
unless someone else picks it up before then, nothing new is going to
happen on it.

thanks,

greg k-h

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Greg KH]

On Tue, Aug 06, 2024 at 11:54:33AM +0800, LidongLI wrote:
> Our requirement is to assign a CVE for this "bug" because it is an issue within the kernel. Since it is a problem, it poses a potential risk. Therefore, we believe it is necessary to address it accordingly.

I know your school professors are making this a requirement for you, but
that is not _our_ requirement here, sorry.  Please work with your school
to find something else to work on.

> Because it involves a driver development error, we believe it is necessary and meaningful to address this issue.

I do not see the driver error yet, please submit a patch showing this
and we will be glad to review it.

thanks,

greg k-h

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Theodore Ts'o]

I was taking a closer look at your reproducer, and there's even a
bigger problem.  Your reproducer runs the moral equivalent of this:

   import usb.core

   dev = usb.core.find(idVendor=0xb58e, idProduct=0x0005)
   dev.reset()

(I've changed the USB vendor/product id's to my Blue Yeti microphone,
so that it was a valid USB device; but that doesn't matter for the
purposes of this demonstration.)

The reset method requires root privileges!

usb.core.USBError: [Errno 13] Access denied (insufficient permissions)

So how does this actually show up in a real life exploit?  The
attacker won't have root privileges, or it's already game over.  If
this is an embedded device, the USB device will be soldered onto the
PC board, so you're not going to be able to plug and unplug it a
hundreds time, with a tenth of a second between plug/unplug cycles
(good luck having a human do that, BTW).

And if you do have physical access, and it's not soldered in -- in
most situations, if you have phyysical access to the device, it's also
likely game over.  For example, you could plug into the debug headers,
and just flash a new firmware onto the embedded device, and again,
game over.

Again, this may very well be a bug.  But not all bugs are real life
security exploits.  This is especially true for syzbot-generated
noise, which runs its "attack scripts" as root.  The excuse given for
this is that it finds real kernel bugs, which may be true (although
others are still syzbot-generated noise); however, not all kernel bugs
are CVE-worthy.

Best regards,

						- Ted

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Alan Stern]

On Tue, Aug 06, 2024 at 09:59:04AM +0800, LidongLI wrote:
> 
> Dear Greg,
> 
> Thank you, Greg!
> 
> 
> Yes, as you mentioned, it requires users to create their own udev 
> rules, which is not common among Ubuntu personal users. However, in 
> some non-personal user scenarios, they must pre-add udev rules to meet 
> their needs. A simple example: in some Ubuntu embedded Linux 
> scenarios, we found that when starting a wireless hotspot, developers 
> must configure udev rules to ensure a stable connection, enable 
> auto-loading of drivers, or auto-run or write USB-based 
> auto-configuration scripts.
> 
> Alright, thank you for your fix. We will proceed to the email you 
> specified to request a CVE.

LidongLI, are you able to test patches?

It looks like the driver does not properly shut down its async queues 
when it unbinds.  The best person to address this problem is the 
driver's maintainer, Stanislaw Gruszka.  Nevertheless, I can help by 
suggesting things to test.

Alan Stern

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Alan Stern]

On Wed, Aug 07, 2024 at 12:47:26AM +0800, color Ice wrote:
> Hi,
> 
> I'm glad that you can address this issue. I believe that this is indeed a
> vulnerability because the issue is caused by the rt2x00 driver's failure to
> properly shut down its async queues. While it requires sudo to execute, it
> is still a problem as it can trigger a kernel system exception. We can
> imagine that this vulnerability could be executed without root permissions
> in certain scenarios. For instance, in many embedded systems, configuring
> udev rules might be necessary to ensure automated operations, and in such
> scenarios, it can be triggered without root permissions.
> 
> Therefore, I believe that from a vulnerability perspective, it should
> indeed be eligible for a CVE, as it can be fixed and it is indeed a flaw.
> If this vulnerability is not addressed, future driver processing and
> adaptation may encounter robustness and security issues. I believe security
> issues should be handled with the corresponding seriousness.
> 
> Thank you.

You didn't answer my question.  Are you able to test patches?

Alan Stern

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[color Ice]

Dear Alan, 、
Thank you for your response. Yes, I am able to test patches. Please
provide the necessary patches, and I will conduct the tests to verify
their effectiveness. Best regards,

Alan Stern <stern@rowland.harvard.edu> 于2024年8月7日周三 02:36写道：
>
> On Wed, Aug 07, 2024 at 12:47:26AM +0800, color Ice wrote:
> > Hi,
> >
> > I'm glad that you can address this issue. I believe that this is indeed a
> > vulnerability because the issue is caused by the rt2x00 driver's failure to
> > properly shut down its async queues. While it requires sudo to execute, it
> > is still a problem as it can trigger a kernel system exception. We can
> > imagine that this vulnerability could be executed without root permissions
> > in certain scenarios. For instance, in many embedded systems, configuring
> > udev rules might be necessary to ensure automated operations, and in such
> > scenarios, it can be triggered without root permissions.
> >
> > Therefore, I believe that from a vulnerability perspective, it should
> > indeed be eligible for a CVE, as it can be fixed and it is indeed a flaw.
> > If this vulnerability is not addressed, future driver processing and
> > adaptation may encounter robustness and security issues. I believe security
> > issues should be handled with the corresponding seriousness.
> >
> > Thank you.
>
> You didn't answer my question.  Are you able to test patches?
>
> Alan Stern

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[LidongLI]

Dear 



Yes, dev.reset does indeed require root privileges, but what we find abnormal is, as I noted in the POC, a normal reset is not problematic. However, after time.sleep(0.1), it triggers some issues.

import usb.core
dev = usb.core.find(idVendor=0xb58e, idProduct=0x0005)
time.sleep(0.1) # It actually needs a sleep of 0.1 or 0.2 seconds to take effect; otherwise, it follows normal development logic. For example, when there is an exception error like 'resource busy', a dev.reset is required.
dev.reset()




Thank you for your response. Yes, I am able to test patches. Please provide the necessary patches, and I will conduct the tests to verify their effectiveness.

Best regards

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[LidongLI]

Dear 



When will the patch be released? We are waiting to test it.




Best regards

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Alan Stern]

On Wed, Aug 14, 2024 at 01:58:16PM +0800, LidongLI wrote:
> 
> Dear 
> 
> 
> 
> When will the patch be released? We are waiting to test it.

Sorry it's taking so long.  I have been extremely busy with other things 
during the last few weeks and have not had any time to work on this.

Alan Stern

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[color Ice]

How is the patch development progressing? We would like to conduct a
full verification test. It’s possible that many drivers have this
issue, so you could try a simple fix, and we’ll see how it works.
Recently, we tested some embedded devices where the operating systems,
due to automated operations involving WiFi drivers, had UDEV rules
built-in or granted significant permissions to USB. This allows the
PoC to cause a kernel crash without needing root or sudo.

Alan Stern <stern@rowland.harvard.edu> 于2024年8月14日周三 22:55写道：
>
> On Wed, Aug 14, 2024 at 01:58:16PM +0800, LidongLI wrote:
> >
> > Dear
> >
> >
> >
> > When will the patch be released? We are waiting to test it.
>
> Sorry it's taking so long.  I have been extremely busy with other things
> during the last few weeks and have not had any time to work on this.
>
> Alan Stern

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Greg KH]

On Mon, Aug 19, 2024 at 06:49:42PM +0800, color Ice wrote:
> How is the patch development progressing? We would like to conduct a
> full verification test. It’s possible that many drivers have this
> issue, so you could try a simple fix, and we’ll see how it works.

This should be unique to this driver, but please, test others.

> Recently, we tested some embedded devices where the operating systems,
> due to automated operations involving WiFi drivers, had UDEV rules
> built-in or granted significant permissions to USB. This allows the
> PoC to cause a kernel crash without needing root or sudo.

But how are you allowed to run local programs on systems that have those
types of permissions?

thanks,

greg k-h

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Greg KH]

On Mon, Aug 19, 2024 at 11:11:10PM +0800, color Ice wrote:
> On some TP-Link routers or routers running OpenWrt, as well as Raspberry Pi
> devices with a headless setup and BeagleBone boards, certain USB
> configurations are required by default. These devices typically grant
> higher permissions to USB by default. Therefore, on certain devices, I can
> run a PoC without using sudo. This explains why there are some inherent
> risk scenarios when declaring this vulnerability, as there are many Linux
> distributions applied to different embedded devices.

I suggest filing bugs with those distros/system images so that they
properly remove the ability for users to reset any random USB device
this way.  If any user can disconnect any driver from any device, that's
not a good system...

Also, why not dig into the code and try to come up with a fix while
waiting?  The code is all there for everyone to read and resolve, that
way you get the proper credit for fixing the issue as well.

thanks,

greg k-h

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[color Ice]

Dear Ubuntu Team,

We have analyzed the issue, but due to our limited time and ability to
create a fix, we are unable to submit a patch directly. However, we
can provide some ideas to assist you in generating a fix that we can
then test.

I have encountered a race condition issue in the RT2X00 driver,
specifically related to the function rt2x00usb_work_rxdone. The issue
manifests as a kernel NULL pointer dereference, which causes the
system to crash. Below is the detailed analysis and my suggestions for
addressing the issue.

Problem Analysis

The kernel panic log indicates that the crash occurs due to a NULL
pointer dereference at the following location:

[ 371.258315] BUG: kernel NULL pointer dereference, address: 0000000000000038
[ 371.258339] CPU: 8 PID: 144 Comm: kworker/u40:2 Not tainted
6.8.0-40-generic #40~22.04.2-Ubuntu
[ 371.258346] Workqueue: phy23 rt2x00usb_work_rxdone [rt2x00usb]

The root cause appears to be a race condition where multiple threads
may simultaneously access and modify shared resources without proper
synchronization. Specifically, it seems that the pointer being
accessed in rt2x00usb_work_rxdone is not consistently initialized
before being used, leading to the NULL pointer dereference.

Suggestions for Fix

Introduce Locking Mechanisms: To prevent concurrent access to shared
resources, I recommend introducing locking mechanisms such as spinlock
or mutex. This would ensure that only one thread can access the
critical section at a time, thereby avoiding race conditions.

Pointer Validity Check: Before dereferencing any pointer, it's
essential to check whether the pointer is valid (i.e., not NULL). If
the pointer is invalid, the function should safely return without
proceeding further.

Retry and Delay Mechanism: If a critical resource is not yet
initialized or is in an unexpected state, implementing a retry
mechanism with delays could help avoid crashes. Additionally, more
debug information should be logged in case of failure to assist in
diagnosing the issue.

Code Review: A comprehensive code review focusing on areas where
hardware resources and multithreading operations intersect could
reveal other potential race conditions. Identifying and addressing
these issues proactively would enhance the driver’s robustness.

Example Code Snippet

While I cannot provide a complete patch, here is an example of how the
suggested changes could be implemented:


void rt2x00usb_work_rxdone(struct work_struct *work)
{
    struct rt2x00_dev *rt2x00dev = container_of(work, struct
rt2x00_dev, rxdone_work);
    unsigned long flags;
    void *data;

    // Lock to protect shared resources
    spin_lock_irqsave(&rt2x00dev->irq_lock, flags);

    data = rt2x00usb_get_rx_data(rt2x00dev);
    if (!data) {
        // Unlock and return if data is not valid
        spin_unlock_irqrestore(&rt2x00dev->irq_lock, flags);
        return;
    }

    // Process the data
    ...

    // Unlock after processing
    spin_unlock_irqrestore(&rt2x00dev->irq_lock, flags);
}


This snippet shows how to introduce a spinlock to protect shared
resources and ensure that the pointer is valid before dereferencing
it.

Conclusion

In conclusion, the race condition in the RT2X00 driver is likely
caused by insufficient synchronization between threads. By adding
proper locking mechanisms, pointer validity checks, and retry
mechanisms, this issue can be mitigated. I hope these suggestions will
assist in resolving the problem. If you require further assistance or
additional information

Greg KH <gregkh@linuxfoundation.org> 于2024年8月20日周二 01:43写道：
>
> On Mon, Aug 19, 2024 at 11:11:10PM +0800, color Ice wrote:
> > On some TP-Link routers or routers running OpenWrt, as well as Raspberry Pi
> > devices with a headless setup and BeagleBone boards, certain USB
> > configurations are required by default. These devices typically grant
> > higher permissions to USB by default. Therefore, on certain devices, I can
> > run a PoC without using sudo. This explains why there are some inherent
> > risk scenarios when declaring this vulnerability, as there are many Linux
> > distributions applied to different embedded devices.
>
> I suggest filing bugs with those distros/system images so that they
> properly remove the ability for users to reset any random USB device
> this way.  If any user can disconnect any driver from any device, that's
> not a good system...
>
> Also, why not dig into the code and try to come up with a fix while
> waiting?  The code is all there for everyone to read and resolve, that
> way you get the proper credit for fixing the issue as well.
>
> thanks,
>
> greg k-h

Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

[Greg KH]

On Wed, Aug 21, 2024 at 04:25:36PM +0800, color Ice wrote:
> Dear Ubuntu Team,

We are not affiliated with Ubuntu at all, sorry.  Please be kind.

> I have encountered a race condition issue in the RT2X00 driver,
> specifically related to the function rt2x00usb_work_rxdone. The issue
> manifests as a kernel NULL pointer dereference, which causes the
> system to crash. Below is the detailed analysis and my suggestions for
> addressing the issue.
> 
> Problem Analysis

<snip>

This mostly looks like it was created with chatgpt or something like
that, please do not send us things like that.

Again, work with your professor at school who has assigned you this task
to complete it, don't force us to do the work for you :)

If we get a chance, we'll look at it, but note it's way down the
priority list for most of us.

thanks,

greg k-h