Your message dated Fri, 9 Jan 2026 17:28:17 +0100
with message-id <[email protected]>
and subject line Re: Bug#1123510: Patch to fix CVE-2025-68146 in 
python3-filelock in trixie
has caused the Debian Bug report #1123510,
regarding python-filelock: CVE-2025-68146
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
1123510: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1123510
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: python-filelock
Version: 3.20.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/tox-dev/filelock/pull/461
X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>

Hi,

The following vulnerability was published for python-filelock.

CVE-2025-68146[0]:
| filelock is a platform-independent file lock for Python. In versions
| prior to 3.20.1, a Time-of-Check-Time-of-Use (TOCTOU) race condition
| allows local attackers to corrupt or truncate arbitrary user files
| through symlink attacks. The vulnerability exists in both Unix and
| Windows lock file creation where filelock checks if a file exists
| before opening it with O_TRUNC. An attacker can create a symlink
| pointing to a victim file in the time gap between the check and
| open, causing os.open() to follow the symlink and truncate the
| target file. All users of filelock on Unix, Linux, macOS, and
| Windows systems are impacted. The vulnerability cascades to
| dependent libraries. The attack requires local filesystem access and
| ability to create symlinks (standard user permissions on Unix;
| Developer Mode on Windows 10+). Exploitation succeeds within 1-3
| attempts when lock file paths are predictable. The issue is fixed in
| version 3.20.1. If immediate upgrade is not possible, use
| SoftFileLock instead of UnixFileLock/WindowsFileLock (note:
| different locking semantics, may not be suitable for all use cases);
| ensure lock file directories have restrictive permissions (chmod
| 0700) to prevent untrusted users from creating symlinks; and/or
| monitor lock file directories for suspicious symlinks before running
| trusted applications. These workarounds provide only partial
| mitigation. The race condition remains exploitable. Upgrading to
| version 3.20.1 is strongly recommended.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2025-68146
    https://www.cve.org/CVERecord?id=CVE-2025-68146
[1] https://github.com/tox-dev/filelock/pull/461
[2] https://github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f
[3] 
https://github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

--- End Message ---
--- Begin Message ---
Source: python-filelock
Source-Version: 3.20.2-1

Hi,

On Thu, Jan 08, 2026 at 10:28:38PM +0100, Sascha Steinbiss wrote:
> Hi Salvatore,
> 
> thanks for your quick reply.
> 
> [...]
> > > Do you think the upload fixing this should target trixie-security or
> > > trixie? I am quite new to fixing things in stable.
> > 
> > The issue is marked as no-dsa, so a DSA and via security is not
> > warranted, but a fix scheduled via an upcoming point release would be
> > great. Can you propose one accordingly for trixie?
> 
> Sure. I can make an upload targeting trixie very soon.

I'm updating as well the metadata for this bug as the issue is fixed
in unstable with the 3.20.2-1 upload.

Regards,
Salvatore

--- End Message ---

Reply via email to