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 摘要。