{"document":{"acknowledgments":[{"urls":["https://kb.cert.org/vuls/id/380058#acknowledgements"]}],"category":"CERT/CC Vulnerability Note","csaf_version":"2.0","notes":[{"category":"summary","text":"### 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.","title":"Summary"},{"category":"legal_disclaimer","text":"THIS DOCUMENT IS PROVIDED ON AN 'AS IS' BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. ","title":"Legal Disclaimer"},{"category":"other","text":"CERT/CC Vulnerability Note is a limited advisory. It primarily identifies vendors impacted by the advisory and not specific products. We only support \"known_affected\" and \"known_not_affected\" status. Please consult the vendor's statements and advisory URL if provided by the vendor for more details ","title":"Limitations of Advisory"},{"category":"other","text":"**Case Statement - WhirlwindFX (SignalRGB)**\r\n\r\nWhirlwindFX has investigated both reported vulnerabilities and confirmed they affect SignalRgbDriver.sys in revisions prior to 1.3.6.\r\n\r\n**VU#380058.1 - Improper Access Control**\r\n\r\nThe `\\\\.\\SignalIo` device object was created without an explicit security descriptor, allowing any authenticated local user to open a handle to the device and issue privileged IOCTLs. This has been remediated in driver revision 1.3.6 via a two-phase caller verification gate enforced in `IRP_MJ_CREATE`. Phase 1 verifies that the calling process image name matches an allowlist (`SignalRgb.exe` or `SignalRgbService.exe`). Phase 2 verifies that the calling process is Authenticode-signed with an EV certificate whose SHA-1 thumbprint matches a value compiled into the driver. Any process that fails either phase receives `STATUS_ACCESS_DENIED` before any I/O operation is performed.\r\n\r\n**VU#380058.2 - NULL Pointer Dereference**\r\n\r\nSeven IOCTL handlers dereferenced `SystemBuffer` without first validating the caller-supplied buffer sizes. With `METHOD_BUFFERED`, `SystemBuffer` is NULL when both `InputBufferLength` and `OutputBufferLength` are zero, causing an immediate kernel crash. All affected handlers in revision 1.3.6 now return `STATUS_BUFFER_TOO_SMALL` when the provided buffer sizes are insufficient before any pointer is accessed.\r\n\r\nDriver revision 1.3.6 will be distributed to SignalRGB users via an application update targeted for release before May 30, 2026. Users are encouraged to update SignalRGB when the update becomes available. WhirlwindFX will recommend that Microsoft add the SHA-256 hashes of all previously shipped SignalRgbDriver.sys revisions to the vulnerable driver blocklist, so that older versions are blocked on systems with Hypervisor-Protected Code Integrity (HVCI) or Smart App Control enabled.\r\n\r\nThe use of kernel drivers to expose hardware I/O to user-mode RGB, fan control, and hardware monitoring applications is widespread across the industry. Many such drivers - including WinRing0x64.sys, inpout32, and inpoutx64 - expose equivalent or broader primitives (arbitrary port I/O, unrestricted PCI configuration access) with no equivalent caller verification, port allowlisting, or signing requirements. Some drivers in this class, notably WinRing0x64.sys, additionally expose direct physical memory read/write IOCTLs - a capability that SignalRgbDriver.sys has never included. WhirlwindFX encourages coordinated review of this driver class more broadly.","title":"Vendor statment from SignalRGB"}],"publisher":{"category":"coordinator","contact_details":"Email: cert@cert.org, Phone: +1412 268 5800","issuing_authority":"CERT/CC under DHS/CISA https://www.cisa.gov/cybersecurity also see https://kb.cert.org/ ","name":"CERT/CC","namespace":"https://kb.cert.org/"},"references":[{"url":"https://certcc.github.io/certcc_disclosure_policy","summary":"CERT/CC vulnerability disclosure policy"},{"summary":"CERT/CC document released","category":"self","url":"https://kb.cert.org/vuls/id/380058"}],"title":"SignalRGB kernel driver contains improper access control and IOCTL vulnerabilities","tracking":{"current_release_date":"2026-06-17T23:57:06+00:00","generator":{"engine":{"name":"VINCE","version":"3.0.42"}},"id":"VU#380058","initial_release_date":"2026-06-17 21:02:43.880551+00:00","revision_history":[{"date":"2026-06-17T23:57:06+00:00","number":"1.20260617235706.3","summary":"Released on 2026-06-17T23:57:06+00:00"}],"status":"final","version":"1.20260617235706.3"}},"vulnerabilities":[{"title":"In SignalRGB versions prior to 1.","notes":[{"category":"summary","text":"In SignalRGB versions prior to 1.3.7.0, seven of the thirteen 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."}],"cve":"CVE-2026-8050","ids":[{"system_name":"CERT/CC V Identifier ","text":"VU#380058"}],"product_status":{"known_affected":["CSAFPID-47c81de6-6ae8-11f1-8284-1253c57fa98d"]}},{"title":"In SignalRGB versions prior to 1.","notes":[{"category":"summary","text":"In SignalRGB versions prior to 1.3.7.0, 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."}],"cve":"CVE-2026-8049","ids":[{"system_name":"CERT/CC V Identifier ","text":"VU#380058"}],"product_status":{"known_affected":["CSAFPID-47c88696-6ae8-11f1-8284-1253c57fa98d"]}}],"product_tree":{"branches":[{"category":"vendor","name":"SignalRGB","product":{"name":"SignalRGB Products","product_id":"CSAFPID-47c81de6-6ae8-11f1-8284-1253c57fa98d"}},{"category":"vendor","name":"SignalRGB","product":{"name":"SignalRGB Products","product_id":"CSAFPID-47c88696-6ae8-11f1-8284-1253c57fa98d"}}]}}