From nobody Fri Apr 10 00:02:15 2026 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 4fsH6c4lvKz6Yq3T for ; Fri, 10 Apr 2026 00:02:16 +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" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fsH6c3Nzmz3y9b for ; Fri, 10 Apr 2026 00:02:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1775779336; 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=lC6S0c4dSZC54DXnDVNUFWWBZ+qlAfLYyqGrEoIUmAI=; b=BfvTFEAv6dtQzTvPxAIMEXt3QFTo8mJoJtxMOWCWWkm7XCYf8FXw13DhDJm6wIetNEfQd1 NaWWbLgJyL1tiamKg/dfpZMOavtDrGJB0V5Dl1RQaOqI+C5rZ7olLMQc36T6pxn2DLZRnL Ai23wKGEOdSwcyI8ndBtQD5zGvsI3YvDub/+r/3hNmaAmo+v1H1sG4zK3gy6CVHvxCF+cV fal/U97Fju5ncNsb0Dw8rqpie8v1Js4DhTir5TDmolQXiyADC1i+KH48VXIt6UCfQ9i0MH p8V/wJ1tVjDWgVhDTHFllI4IsigsK8iviFYDL2IHsPgADAm2ipnbMvtVuC0jlg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1775779336; a=rsa-sha256; cv=none; b=yVEJUaLMNVBVv0EGpOVe2rEdZaVFkUMTuehpxAG7sFFjz9vqDhFIGt7zQaI8sQVpCqrymc 9R7qOrvRGXRDyaZbSFQC+QpXSEgB5EzP4h9UZblqEFm2RRdapoVz3vM+IfzyHnWxbcZfx0 bPOQnBJqiHN8DnKK/y4X1yU13SGlEP9ul+Dda4T4eWKlaJYhI1LFd5lgv3MI7RNqZfDfpe 9eTQ3rr2d3BzaEaSkT4SyQKNOMeUma1s140evFkyD0GZIkxyq83jD3CEY7VjPsUMSoDCiB Bf2g1Ee/ZvjDsW9N6PfXd00bHHmLRgpChJ9M5ygMa4mER2pBbMOk73WZuDo1vw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1775779336; 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=lC6S0c4dSZC54DXnDVNUFWWBZ+qlAfLYyqGrEoIUmAI=; b=QEqu7WASXpHiYCOyMH7Udt5bUQ1Mf4VyVzPqgNch+8/KyQl4JUI4TGwfOGBLD/V/An4zZc Si0FGoVQqmIlZO14YLuzbj+V3gvkfT/0IDTwZWSgA8+ckB4mmNIoZcS7bMajOy32ce8cwN D3mPSyfsMgF0KA3aw4EftgTD928Tyz+EOxMlMYsZ/N6ATCaFXPQwv1zCctqD+AQ0V1SRbQ dM1WP1pcW4eFOTt4uj55TAafkV/2yzN0HOfMTZAqf6My7avVco8oYyOn8b70Pva/csmXB0 iEiZH//MP/mpiwAb44isjaiWhtVn/0YF97OiJJdtvrRzZIEoL3ZY94tXgdnyng== 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 4fsH6c2yfxz4m5 for ; Fri, 10 Apr 2026 00:02:16 +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 63A02GxC027209 for ; Fri, 10 Apr 2026 00:02:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 63A02Gvu027208 for bugs@FreeBSD.org; Fri, 10 Apr 2026 00:02:16 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 293382] Dead lock and kernel crash around closefp_impl Date: Fri, 10 Apr 2026 00:02:15 +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-STABLE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kevans@freebsd.org 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=3D293382 --- Comment #51 from Kyle Evans --- (In reply to Paul from comment #49) Just thinking out loud for a minute, we know these facts: 1.) In slot 211098 of this kq we found this knote that thinks it is for fd 76954 and has an fp that matches fd 76954 in the fd table 2.) The kq_knlist only ever grows, never shrinks, and in exactly one place: kqueue_expand 3.) kq_knlist / kn_link usage is actually pretty minimal and reasonably ea= sy to audit 4.) knote_attach is the only place adding anything to kq_knlist knote_attach() is incredibly straightforward and clearly under the kq lock: 2880 if (kn->kn_fop->f_isfd) {=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 2881 if (kn->kn_id >=3D kq->kq_knlistsize)=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2882 return (ENOMEM);=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2883 list =3D &kq->kq_knlist[kn->kn_id];=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2884 } else {=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2885 if (kq->kq_knhash =3D=3D NULL)=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2886 return (ENOMEM);=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2887 list =3D &kq->kq_knhash[KN_HASH(kn->kn_id, kq->kq_knhashmask)];=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 2888 }=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2889 SLIST_INSERT_HEAD(list, kn, kn_link);=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 That's clearly checking the size correctly beforre it inserts the knote. T= he only removal is in knote_drop_detached(): 2925 if (kn->kn_fop->f_isfd)=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 2926 list =3D &kq->kq_knlist[kn->kn_id];=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2927 else=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2928 list =3D &kq->kq_knhash[KN_HASH(kn->kn_id, kq->kq_knhashmask)];=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2929=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 2930 if (!SLIST_EMPTY(list))=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 2931 SLIST_REMOVE(list, kn, knote, kn_link);=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 I think we all agree that !SLIST_EMPTY(list) should actually be an assertio= n at best, there's no path before the call to knote_attach() in kqueue_register() that would call knote_drop*() and you can't double-drop a knote. I really don't see many plausible causes here, outside of kqueue_expand goi= ng wrong somehow, but the disassembly seems sane (and not obviously eliding important things) and the bzero calculations, while kind of convoluted, seem fine. I probably would've written it as bzero(&list[kq->kq_knlistsize], (s= ize - kq->kq_knlistsize) * sizeof(*list)) personally, but I don't see a world in which those aren't equivalent. --=20 You are receiving this mail because: You are the assignee for the bug.=