Description

OpenPrinting CUPS before 2.4.20 contains a double-free in printer-class management. When CUPS-Add-Modify-Class replaces an existing class member list, add_class() frees pclass->printers without clearing the pointer. If subsequent validation fails, the class retains the dangling pointer; CUPS-Delete-Class subsequently frees the same allocation in cupsdDeletePrinter(). A client authorized to modify and delete classes can cause scheduler-wide denial of service. The default policy requires @SYSTEM privileges.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "2.3",
  "pubDate": "2026-10-09T04:18:05.163Z",
  "pubdate": "2026-10-09T04:18:05.163Z",
  "executiveSummary": "OpenPrinting CUPS versions prior to 2.4.20 are susceptible to a critical double-free vulnerability within the printer-class management subsystem. The flaw arises from improper memory management during the modification of class member lists in the CUPS-Add-Modify-Class operation.\nIf the validation process for a printer class fails after the existing member list has been deallocated, the application maintains a dangling pointer to the freed memory. Subsequent invocation of CUPS-Delete-Class via cupsdDeletePrinter() attempts to free the already deallocated memory, resulting in a double-free condition. This error triggers a scheduler-wide process crash, leading to a Denial of Service (DoS) for the entire printing system.\nThe vulnerability is restricted to authenticated users possessing @SYSTEM privileges, as defined by the default CUPS policy. An attacker capable of modifying and deleting printer classes can weaponize this memory corruption to destabilize the scheduler, effectively disrupting all print services managed by the CUPS daemon.",
  "technicalDetails": "The vulnerability is located within the printer-class management logic of the CUPS scheduler, specifically within the add_class() function. The root cause is a failure to sanitize pointers following memory deallocation during the CUPS-Add-Modify-Class request process.\nWhen a user submits a request to replace an existing class member list, the scheduler invokes add_class(). This function frees the existing memory pointed to by pclass->printers in preparation for the new list. However, the function fails to set the pclass->printers pointer to NULL immediately after the free() operation. If the subsequent validation logic fails for the new printer class definition, the execution path exits while pclass->printers still holds the address of the previously deallocated memory, creating a dangling pointer.\nThe exploitation flow is as follows: 1) An attacker with @SYSTEM privileges initiates a CUPS-Add-Modify-Class request with a malformed printer class that is designed to pass initial processing but trigger a failure during the final validation stage. 2) The add_class() function executes, deallocates the existing pclass->printers memory, and then encounters the validation error, leaving the dangling pointer intact in the internal class structure. 3) The attacker then invokes the CUPS-Delete-Class operation, which calls cupsdDeletePrinter(). 4) Within cupsdDeletePrinter(), the routine attempts to free the same memory block originally held by pclass->printers.\nBecause the memory has already been returned to the heap allocator by the initial failed modification request, the second call to free() triggers a double-free fault. Depending on the memory allocator's implementation (e.g., glibc's malloc behavior), this corruption typically results in an immediate SIGABRT, forcing the cupsd scheduler to terminate abruptly. Given that CUPS manages the global printing state and multiple print jobs, this crash results in a complete Denial of Service for all users of the printing system.\nThe vulnerability affects OpenPrinting CUPS versions before 2.4.20. Successful exploitation requires the attacker to authenticate with @SYSTEM-level privileges. While the attack is limited to authorized users, the potential for persistent service disruption poses a significant threat to organizational print infrastructure availability."
}