{"vuid":"VU#380058","idnumber":"380058","name":"SignalRGB kernel driver contains improper access control and IOCTL vulnerabilities","keywords":null,"overview":"### Overview\r\nThe SignalRGB kernel driver, `SignalIo.sys`, contains two vulnerabilities involving improper access control and unsafe memory handling. The device object is created with an overly permissive Discretionary Access Control List (DACL) that allows user-mode processes to access privileged hardware operations through input/output control (IOCTL) commands. Additionally, several IOCTL handlers are susceptible to NULL pointer dereference conditions, which further enables low-privilege users to trigger kernel crashes and cause Denial of Service (DoS). Version 1.3.7.0 of the SignalRGB driver remediates these vulnerabilities. \r\n\r\n### Description\r\nSignalRGB is a Windows application used for RGB lighting control and hardware monitoring. Its kernel component, `SignalIo.sys`, provides the low-level interfaces required to access and interact with hardware resources. \r\n\r\nThe `SignalIo.sys` driver exposes privileged functionality intended for administrative or security operations, but the device object is created without a restrictive security descriptor. Specifically, the driver does not apply [security best practices](https://learn.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-definition-language) by using either Security Descriptor Definition Language (SDDL) or the IoCreateDeviceSecure API, thereby allowing unprivileged user-mode processes to open handles to the device and issue privileged IOCTL requests.\r\n\r\n**CVE-2026-8049** The `\\\\.\\SignalIo` device object is created without an explicit SDDL security descriptor and without `FILE_DEVICE_SECURE_OPEN`. This results in overly permissive default access control, allowing any authenticated local user to obtain a handle to the device and issue privileged IOCTLs.\r\n\r\n**CVE-2026-8050** Seven of the sixteen IOCTL handlers dereference the `SystemBuffer` pointer without first verifying that it is non-NULL. Sending an IOCTL with an empty input buffer causes a NULL pointer dereference, resulting in a kernel crash.\r\n\r\n### Impact\r\nThe device's insufficient access control enables user-mode interaction with privileged IOCTL interfaces and sensitive driver functionality, including read/write access to the PCI configuration space of system devices. Additionally, an authenticated local attacker can trigger repeated kernel crashes by accessing the `\\\\.\\SignalIo` device and sending NULL input buffers to any of the seven vulnerable IOCTLs. \r\n\r\nNotably, the affected SignalRGB drivers already include custom kernel-enforced port whitelists to block I/O access to several high-risk ports, which helps to limit the scope of sensitive operations available through the IOCTL interface. \r\n\r\n### Solution\r\nSignalRGB has remediated these vulnerabilities in the recent 1.3.7.0 driver release. Users and organizations should update and/or block the previous vulnerable driver version where possible and implement mitigations designed to reduce exposure to BYOVD attacks, including restricting administrative privileges, enforcing Microsoft's [recommended driver block rules](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules), and enabling protections such as Windows Defender Application Control (WDAC) or an equivalent EDR solution for your environment.\r\n\r\n### Acknowledgements\r\nThanks to Shravan Kumar Sheri for researching and reporting this vulnerability, and to SignalRGB for their prompt engagement and remediation efforts. This document was written by Molly Jaconski.","clean_desc":null,"impact":null,"resolution":null,"workarounds":null,"sysaffected":null,"thanks":null,"author":null,"public":[],"cveids":["CVE-2026-8049","CVE-2026-8050"],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2026-06-17T21:02:44.075369Z","publicdate":"2026-06-17T21:02:43.880551Z","datefirstpublished":"2026-06-17T21:02:44.088207Z","dateupdated":"2026-06-17T23:57:06.991166Z","revision":3,"vrda_d1_directreport":null,"vrda_d1_population":null,"vrda_d1_impact":null,"cam_widelyknown":null,"cam_exploitation":null,"cam_internetinfrastructure":null,"cam_population":null,"cam_impact":null,"cam_easeofexploitation":null,"cam_attackeraccessrequired":null,"cam_scorecurrent":null,"cam_scorecurrentwidelyknown":null,"cam_scorecurrentwidelyknownexploited":null,"ipprotocol":null,"cvss_accessvector":null,"cvss_accesscomplexity":null,"cvss_authentication":null,"cvss_confidentialityimpact":null,"cvss_integrityimpact":null,"cvss_availabilityimpact":null,"cvss_exploitablity":null,"cvss_remediationlevel":null,"cvss_reportconfidence":null,"cvss_collateraldamagepotential":null,"cvss_targetdistribution":null,"cvss_securityrequirementscr":null,"cvss_securityrequirementsir":null,"cvss_securityrequirementsar":null,"cvss_basescore":null,"cvss_basevector":null,"cvss_temporalscore":null,"cvss_environmentalscore":null,"cvss_environmentalvector":null,"metric":null,"vulnote":206}