From nobody Tue Sep 30 14:01:48 2025 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cbfqw3hrQz6989n for ; Tue, 30 Sep 2025 14:01:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cbfqw1mQqz49h6 for ; Tue, 30 Sep 2025 14:01:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759240908; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=qZs32pLOyOkriyTRpSNildYERjSJmb7fOEi4wsSgMCU=; b=JwP7FpWH/0u1HzGjO1KqEQB2QERM1/+lr9H4XQF9fRkTYddNrWyzwwLUakA7IjOKoR7l5l BoWRtZdxsxBGvFjQxerhzATPwU5Uywp11WHsKD0dlDRqfv9myZUL1bOykn71e14RY2OQkN wU1quUFJ2pLl+Y+48spCgIVSJJ8tjYadJxLDYYFasuWzYLDkuK1HbtpSQP0K/AqkFYy1Qa 3dKkxwyrpdSH+R30WKwP8aCPNCE7bW15dXUdVTxrUejJEPHCHQNAwL7LY+J2HnQ4xsDif6 L4ZaKqycFObm3jryFhBqZkUn3R9Wi5NGbzYRzg9rI6ImGs5Zv32KmjURZP+6bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759240908; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=qZs32pLOyOkriyTRpSNildYERjSJmb7fOEi4wsSgMCU=; b=B0NDzTBwYHq/NytyQPhquyi3LxGWMyRgvUn5tBifwRQ7MBa4H4AE95OyzxPZVdfSvo+8TI kfckR93ykcLrr9i5fd8iB0GEyP8n1Ti089x8Pn/ilugV72VfdEedVOM/INgleGNDleI8zt cPeiTTGCsBO81otc0rrGBaMLExQMtalawzq4zmLQEi/eGJWQW81fOWfZisU9bvVR1AWc/6 PMYzOdpy98F8CrhKZEMWw8bf1j2aUFm+Fja8BZpEiSrWaKTDRoplSEqarDYyDJBG2gZis3 1RUp+5lc/Rw+1/J5iKld1nbiFmSK2oObx6EQ87sdtZhJzoD9ZA8f7ARLjH+ktg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1759240908; a=rsa-sha256; cv=none; b=WXOnhswKWhVBeFAHQtomxtC+CwBjMLzgZX4FhhwlHPYwY7PwQBsuTPA6/2nKrw+a+ymR9Y UO3ZrYPxhc3g0XrAMbRX09QKOGabf9H26FkadeLFLIOVf5xpAemoTrO7WKiucjGNRTyO+m If+myRcJdQkkL8sAFwuGSFeEpInSTMVDko7LxuKNVF6kABtgF6Sb5tXLRBjf36P8lS0xeo lSrIEBZcqvMJ9oZQN3CJjJqBC2MNsvQsfHcn/wX2AcRGdaAGfyN9RZ1oJC5lySG0+LDISp /gutmFuHognLnL/uItnBkXGFuccQ9kCoofMB8lzWUaIMc3PE1XEZM7uZkAlx9Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4cbfqw1N97zgCw for ; Tue, 30 Sep 2025 14:01:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 58UE1muk089549 for ; Tue, 30 Sep 2025 14:01:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58UE1mUW089548 for bugs@FreeBSD.org; Tue, 30 Sep 2025 14:01:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 289917] PID leak in proc_id_reapmap Date: Tue, 30 Sep 2025 14:01:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D289917 Bug ID: 289917 Summary: PID leak in proc_id_reapmap Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: avg@FreeBSD.org I have an easy way to reproduce a PID leak in proc_id_reapmap using timeout= (1) command. It does not require any elevated privileges, that is, it can be done as a regular user. The leak is readily reproducible using these versions of FreeBSD: 14.3, stable/13, 13.5. The leak is a bit harder to reproduce on main, stable/15, upcoming 15.0, stable/14. What I mean by a bit harder is that the leak is not reproducible in a defau= lt installation, but if I take a copy of timeout(1) command from an affected version (e.g., 14.3), then I can reproduce the leak using the command. I conclude that the kernel allows for a resource leak via procctl(2). In the affected versions, timeout(1) has some bug(s) which trigger the reso= urce leak. In newer versions, timeout(1) is much better behaved but procctl(2) can sti= ll be "exploited". By filling proc_id_reapmap it's possible to create a situation where no new= PID could be allocated. An attempt to do so would get stuck in an infinite loop in fork_findpid. Subsequent attempts would be blocked on procid lock. To reproduce the issue I use a small script that kills itself like this: #!/bin/sh sleep 0.0001 ; kill $$ Then I run the script under timeout(1) like this: timeout 0.01 ./timeout-test.sh Or in a loop for a more pronounced effect: while true ; do timeout 0.01 ./timeout-test.sh ; done proc_id_reapmap can be checked using a custom gdb function like: define bitset_count set $bitset =3D $arg0 set $bitcount =3D $arg1 set $c =3D 0 set $i =3D 0 while ($i < $bitcount) set $n =3D $i / 64 set $b =3D $i % 64 if (($bitset[$n] & (1ul << $b)) !=3D 0) set $c =3D $c + 1 end set $i =3D $i + 1 end print $c end Example from a test on 14.3 (running the command just moments apart): (kgdb) bitset_count proc_id_reapmap 100000 $1 =3D 23 (kgdb) bitset_count proc_id_reapmap 100000 $2 =3D 1485 According to my brief research the userland misbehavior of timeoout(1) was fixed by the commit series to bin/timeout done on April 16 (2025) by bapt, = with most of those changes authored by Aaron LI. --=20 You are receiving this mail because: You are the assignee for the bug.=