Bug 2364203 (CVE-2025-46805)

Summary: CVE-2025-46805 screen: Race Conditions when Sending Signals
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Screen. A possible denial of service caused by race conditions when sending signals exists. The `CheckPid()` function drops privileges to the real user ID and tests whether the kernel can send a signal to the target PID using these credentials. The signal is sent later via `Kill()`, potentially using full root privileges. By this time, the previously checked PID could have been replaced by a different, privileged process. It might also be possible to trick the privileged Screen daemon process into sending signals to itself since a process is always allowed to send signals to itself.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2383360, 2383361    
Bug Blocks:    

Description OSIDB Bzimport 2025-05-05 20:20:41 UTC 
In socket.c line 646 and line 882  time-of-check/time-of-use (TOCTOU)
race conditions exist with regards to sending signals to user supplied PIDs in
setuid-root context.

The `CheckPid()` function drops privileges to the real user ID and tests
whether the kernel allows to send a signal to the target PID using these
credentials. The actual signal is sent later via `Kill()`, potentially using
full root privileges. By this time, the PID that was previously checked could
have been replaced by a different, privileged process. It might also be
possible to trick the (privileged) Screen daemon process into sending signals
to itself, since a process is always allowed to send signals to itself.

Currently this should only allow to send SIGCONT and SIGHUP signals, thus the
impact is likely only in the area of a local denial of service or a minor
integrity violation.