Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

`uuid.uuid4()` can generate duplicates

未关闭
  • 哪里不对？
#160,215 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
42/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
linux, python
领域
backend, security

调研方向

Start by reading the C UUID implementation in Modules/_uuidmodule.c, especially gen_random_lock_held and the random_buf PID check described in the report. Reproduce the duplicate UUID with the provided PID namespace proof of concept on Linux, then investigate how the cache behaves across process forks and PID reuse. Done means uuid.uuid4() no longer produces duplicate values in the reported scenario, with a regression test covering it.

由索引模型根据 Issue 内容生成。

描述

extension-modules type-bug
Bug report

https://github.com/python/cpython/pull/139123 rewrites the uuid module to be in C. On its face, that's fine; however, it also adds an entropy cache to the C uuid module. See gen_random_lock_held, with specific attention to this portion.

It contains the following comment:

    // Overfetching & caching entropy improves the performance 10x.
    // There's a precedent with NodeJS doing exact same thing for
    // improving performance of their UUID implementation.

For context, I'm looking because NodeJS today also released CVE-2026-106074, an error in their equivalent cache.

Specifically, the CPython entropy cache (state->random_buf) is in memory; it will regenerate it if:

    if (pid != state->random_last_pid) {

Read this as "current pid != the pid that created the buffer".

Linux (but this applies to at least macOS as well) do not guarantee that PIDs are unique across a boot. In Linux, there are two circumstances in which a child might see the same PID as a parent or ancestor:

  • The PID has been recycled, and the ancestor has died.
  • The process is in a separate PID NS, and is seeing the same PID that an ancestor (including, possibly, the parent) witnessed in a different NS.

Either case, I believe, can be used to generate duplicate UUIDs.

I started with the latter case when I was hacking this up: say I am the first process in a container; in Linux, such a process is "init" for that PID NS, and will always be PID 1. If that process itself creates child inside a new container, that child will also be PID 1. Since the child then sees that the pid is "unchanged" since state->random_buf was generated, it will not re-create the buffer, and we can end up with two processes with the same random_buf buffer.

A proof of concept 
import ctypes
import os
import signal
import sys
import time
import uuid

# Define Linux clone flags
CLONE_NEWPID = 0x20000000
CLONE_NEWNS = 0x00020000
CLONE_NEWUSER = 0x10000000

libc = ctypes.CDLL("libc.so.6", use_errno=True)


def unshare(flags):
    res = libc.unshare(flags)
    if res != 0:
        err = ctypes.get_errno()
        #print("error :(")
        #time.sleep(100)
        raise OSError(err, os.strerror(err))


def dream_child():
    # Unshare PID namespace (and user/mount namespaces for full isolation)
    #unshare(CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWUSER)
    #print("unsharing.")
    unshare(CLONE_NEWPID)

    # Fork is required because the current process stays in the old PID namespace;
    # only its future children enter the new PID namespace.
    pid = os.fork()

    if pid == 0:
        # We are inside the new PID namespace (Child process)
        print(f"Child process PID in *new* new namespace: {os.getpid()}")

        print("In dream level 2.")
        print(f"uuid4() in child  -> {uuid.uuid4()}")
        sys.exit(0)
    else:
        # Parent process waits for child
        _, status = os.waitpid(pid, 0)


def main():
    # Unshare PID namespace (and user/mount namespaces for full isolation)
    unshare(CLONE_NEWPID)

    # Fork is required because the current process stays in the old PID namespace;
    # only its future children enter the new PID namespace.
    pid = os.fork()

    if pid == 0:
        # We are inside the new PID namespace (Child process)
        print(f"Child process PID in new namespace: {os.getpid()}")

        # Optional: Mount a new /proc so tools like 'ps' work properly
        # (Requires CLONE_NEWNS)
        try:
            os.mount("proc", "/proc", "proc", 0, "")
        except Exception:
            pass

        # Burn a UUID to set the cache up.
        uuid.uuid4()
        print("In dream level 1.")
        dream_child()
        print(f"uuid4() in parent -> {uuid.uuid4()}")
    else:
        # Parent process waits for child
        _, status = os.waitpid(pid, 0)
        sys.exit(os.waitstatus_to_exitcode(status))


if __name__ == "__main__":
    main()

On my system, this Python script emits:

» sudo ~/code/third-party/cpython/python unshare_and_uuid.py
Password: 
Child process PID in new namespace: 1
In dream level 1.
Child process PID in *new* new namespace: 1
In dream level 2.
uuid4() in child  -> 1df59e77-c35a-4921-afa7-98e653300c67
uuid4() in parent -> 1df59e77-c35a-4921-afa7-98e653300c67

Note that you do not need PID NSes for this to work. The first bullet in the list above would function something like,

  1. In the initial process, call uuid.uuid4() to prime random_buf; let's call this pid A, so random_last_pid is A.
  2. Fork, let the parent die; PID A is now free.
  3. In a loop, spawn children until you obtain PID A. In the child, if the child's PID is A, generate a UUID.
  4. All children where the child PID is A will obtain the same UUID.

(This has the benefit of not needing ctypes or PID NSes to accomplish.)

(Note that the PID NS example requires root, in order to unshare the PID NS. Unsharing the PID NS as a normal user should also be possible, but it requires more setup that I didn't want to hassle with. I.e., it should be possible to write a more complex PoC that doesn't require sudo, so I wouldn't focus on that.)

(Admittedly, the circumstances required for this might be difficult to run into.)

CPython versions tested on:

CPython main branch

(n.b., at the time of writing, this only applies to main. The latest released version, 3.15.1, does not contain the bug discussed here.)

Operating systems tested on:

Linux

主要语言
Python
星标
77.7k
派生
38.3k
平均合并
14 小时 29 分钟
30 天内合并 PR
699

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

python/cpython 的其他 Issue

查看 python/cpython 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。