Search code, repositories, users, issues, pull requests...
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
The lock acquired here doesn't get unlocked until the IPP server has responded. A malicious IPP server can keep the connection going effectively remotely causing a DoS of the service.
I believe there's also a race condition because internally examine_discovered_printer_record then tries to unlock and relocks after a while.
We should review the locking and multi-threading implementation in cups-browsed to ensure we don't deadlock and don't wait indefinitely for a printer to respond. In particular, a short timeout (10 seconds?) should be set on any printer connection so that we minimize the chances of a misbehaving printer from preventing cups-browsed from setting up local print queues for legacy applications.
Do you realize that there's tons of people observing these repos and the commits you have been pushing on the public branches for days now instead of following the suggested procedure for GHSAs?
