From nobody Tue Sep 30 10:18:29 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 4cbYtF1vG2z68qv6 for ; Tue, 30 Sep 2025 10:18:29 +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 4cbYtF1P3xz3MKk for ; Tue, 30 Sep 2025 10:18:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759227509; 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: in-reply-to:in-reply-to:references:references; bh=GNzOnfMDbbhsJxa0PEmoYJK1Lw+y9IOqRAC3xpj3rL0=; b=Rp1n/yYOq2E/Hiiv/db0HCVU5USghG96MdS394Yr4xs19u5NY3EbWsUop93v0S++WC+PiR S+mfwyFlkkfg/HtmGM83fMHsEmO8/Hhne0Oa8E8lo6/TsBCD/lIopWFuTx+3ShJQnfvQEh 6hFAIlbeN6DhLyEmDbukmpxf5kC4S7Mbj+S8PsfQeCTUlqarj/MpCyTS+bNS8GEslFMpG7 S5L17737TWhU8/9m9wdykAaJjMWbSHNztMyBaWukogJPcIz3REcZMMaqWgRgz6gq2aoXyK 1Oxbjk2E/MKELOePG/EGKik9SbySMMT6Dys1548f5bLs8/6eGKMK3SfonDW/tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1759227509; 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: in-reply-to:in-reply-to:references:references; bh=GNzOnfMDbbhsJxa0PEmoYJK1Lw+y9IOqRAC3xpj3rL0=; b=lhPh+AJoO12xPo5iJtRPdbsl50fe9wcPTU/LNgEgUAagW+LOqJ5H8d9EMQoRInooLT34uj s3xt+GqvLCmCDhVIzIUeY3fe2mPkeRhVbi7VyB3HOML+1TgNHX8CVZNKrC6USZy5HUnT9u 9gwkhAgk0QYJOMgJMnY2KyHeY4jf+3AdbHyLsnqmBktkTcuPm3lZDRgEJaIikYWu0DOyNs r5ALz+/ICl3PtM8aau1CoF/DswfqRg1wPVFuXGoEUKf7Av5leXnsMZfu4xvv8KggJ6yhYY m4CYUVYBv97/VqnDdz25y+QU5Iw+htPBjs+ySRHEFGwbDGFVt6sud5xZbHb4vQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1759227509; a=rsa-sha256; cv=none; b=XADYnSdslXvTbsueSFkJ1dETent6/zRC7b2mdqyTDADfoSAUt3Oo693PT6lCDDJuYe79RX 5vzFovxY8Bkhn5O4zdZGZvgWjfjI9P4eG+oAfkTzfYsuALDZ8X/+DHA7g6iERDxLBKaSAy 7u3Qz6eD8rx506y6FpavbfSG9DbtKXleEjBbG9Dw1s6EMDDKlpxEOeyCOsooG9JyfbD6rU ZfqGijMBqb2kUwj/aBjQvkocttbPszHafGz0Ap5IOpJA6dIkUYFqBWhJolSc4HoX6Egt+n hxSHDZTstsYt/AG0IEH+m8SdNjisvzJ3onbbG6kbhr2xix4U00XgMlaHEidvpA== 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 4cbYtF0ykszY4W for ; Tue, 30 Sep 2025 10:18:29 +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 58UAIT7t048556 for ; Tue, 30 Sep 2025 10:18:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58UAIT4g048555 for bugs@FreeBSD.org; Tue, 30 Sep 2025 10:18:29 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 289120] A time-of-check to time-of-use race exists in gpioc_kqread() of GPIO subsystem Date: Tue, 30 Sep 2025 10:18:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: chenqiuji666@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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=3D289120 --- Comment #7 from Qiu-ji Chen --- (In reply to Ahmad Khalifa from comment #6) Hi Ahmad, Thank you for confirming the ioctl race and for the detailed explanation of= the kqueue locking mechanism. You are absolutely right about knlist_init_mtx; our static analysis and man= ual audit completely missed that initialization path. We appreciate the clarification and will work on improving our tool to correctly handle this pattern. Based on your explanation, the expectation is that filterops->f_event will always be called with the knlist lock held. With this understanding, we reviewed the call sites in /sys/kern/kern_event.c. We found that while 5 of= the 6 calls to f_event do hold the lock, one in knote_fork() appears to be miss= ing it. In that function, the knlist lock is released at line 573 but not re-acquired until line 610, leaving the call to kn->kn_fop->f_event(kn, NOTE_FORK) at line 608 unprotected. Perhaps the lock acquisition at line 610 should be moved before this call? On a related note, the comment for struct knote in /sys/sys/event.h mentions that fields like kn_sfflags are protected by the knlist lock, but it doesn't state that the kn_fop callbacks are also expected to be called under the lo= ck. It might be helpful to update this comment to make the locking requirement explicit. So far, I have only audited the call sites for f_event, but it se= ems possible that other function pointers in filterops might also have call sit= es that violate this locking assumption. I will continue to review them, but wanted to bring this potential pattern to your attention. In Linux, a tool = like lockdep is very effective for catching these locking violations. I am not familiar with the equivalent in FreeBSD, but perhaps adding assertions could help verify the rules. Thanks again for your time and help. Best regards, Qiu-ji Chen --=20 You are receiving this mail because: You are the assignee for the bug.=