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,
