From nobody Mon Jun 22 16:50:55 2026 X-Original-To: freebsd-security@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 4gkZ2n3FZBz6hYkN for ; Mon, 22 Jun 2026 16:50:57 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "YR1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gkZ2n27DVz3S1N; Mon, 22 Jun 2026 16:50:57 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1782147057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z3jwrJ/ldKBrnGk/hEhBEeCAUAERipg4bZGLgVBTHWw=; b=FyCMK8k+f64ZEY66m9kWAdgyUiWQdYfqIWdkUcKmMpQiVwQxwgdfyQbGR3Bo9PAY8Q+58p cnMHbO1OWz5s5oyQG0Zm/RYLp2I9dgm+ZksCaz38ogMHIFy0gMb6EYWul2sBW9HIDyw36S 5l6aBcI/gChMx2NcX33oK/8Sp3sTpE6DhyFmDgisQMZ/1mzuItoOhfD8lVTEG7ZYklXHwu aRBGAVxelrGJh+KhyV3B5kMcKyJ7GhTlGXukD1bixGxlphL2sW/TrMYS5iDFyKaba5LYYN 6jtu01UCJkj6RBnfV3TwdUKl8g+aW/aKB2fbjQUYBILZldRDgAFFCt1+Jm1LBg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1782147057; a=rsa-sha256; cv=none; b=ZPnnT0Ot3vsbFc9ZA9ac3aqyCjSBB+kEhy1P1Z6nusDWDLuBHTDOt2liT/GE22sVazSw6e aEVUxfSyBKh/b2fN8tScObyBoKss7lmNmGFk3DTVf7+hgdOEPqDQe+srKgG7v0mvmrtaG2 PiSdZVKKXCOXYly+zlZScCwSdn2PY2t5vpG24+GC0wvWhYouVm0APM9XMMQoA/WFftuqkf vQUEqoXcxkjfScejE9XEtuietziunDWFalLZPtmKDtK0LLRAptO2o/D/GLlmDXe39GKuoi qgUbE7R2UG0BWbzZ5WlHQdfx4bZDqQYc4ywfPWZaqFmYLXu9A2RAc1mZ+Gri9A== 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=1782147057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z3jwrJ/ldKBrnGk/hEhBEeCAUAERipg4bZGLgVBTHWw=; b=d6nE3Jt6WEt6d/Usjad9ItGqToaFDfHzzpD2hYKoOnlz8mc1H1iKSalZjJv6/BNFPLaNFW 4VX1nwQ8zu8YD3fisdFK02nUPmMXy9a1f/luixwaMFJ/u8eGzwe613+uYJYOjJjRya2vbB AkRAew5Kiw+CJ5cWYeTukdR5Nj1Guz4KvGytoqsKM/sPSy2eKUHHhP0szSR+CcnNomcdMw FfGJvDpWNvOawU4BUUSvxa4fdB9NfMYPXrz1Z2lRJCIC7Uy29awU2ZDxiUREoSFovE+ed0 7hpB9g/TA5Vac7BrWQsb+lOsQikZ5HPPLUiuU5MJgtkdjTyVg7emr++8b5+6Cg== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4gkZ2m3LJLzL3S; Mon, 22 Jun 2026 16:50:56 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <0ca87be3-9359-4cbb-af7d-51faeedce0a7@FreeBSD.org> Date: Mon, 22 Jun 2026 11:50:55 -0500 List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: =?UTF-8?Q?Re=3A_FreeBSD_14=2E3_auditd_Zombie_Issue_=28Bug_=23295840?= =?UTF-8?Q?=29_=E2=80=94_Request_for_Direct_Technical_Alignment?= To: Anuj Telkhade , "des@FreeBSD.org" Cc: Amit Gopal Patil , Rajan Singh , Vedashri Magare , Spencer Brown References: Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit (Dropping freebsd-bugs@ and freebsd-security@ to BCC, because this kind of communication shouldn't really go there) On 6/22/26 02:40, Anuj Telkhade wrote: > Hi Team, > Hello! > We are observing an issue on FreeBSD 14.3 where auditd appears to accumulate zombie child processes during frequent audit trail rotation. The issue is seen on systems with high audit event volume and relatively small audit trail file size configuration. Under this condition, audit trail files rotate frequently. Each rotation appears to invoke /etc/security/audit_warn with the closefile argument. Over time, multiple audit_warn processes remain in a defunct/zombie state. > > Please check more details on this reference ticket - 295840 – Accumulation of zombie processes on FreeBSD 14.3 systems during sustained high-volume audit trail rotation on vendor machines , > > To expedite troubleshooting we need freeBSD team's regular calls and direct alignment with Qualys team for solution. > > Let us know your convenient time to sync up.> I'm sorry that we haven't been able to figure out what's happening in your scenario yet, but this isn't really how the FreeBSD project works. The mailing list and bugzilla are both directed to folks largely working on a volunteer basis. Some bugs do see some sponsored effort for reasons that aren't always broadcasted, but interactive support isn't something that the project is able to provide regularly- this is why companies like Klara[0] exist to fill in the gaps. Some of the commits against your PR have been sponsored by Klara because we've done previous work in the OpenBSM space and I was able to secure us some time to work on this, but I can't really justify more synchronous debugging efforts at the expense of our paid engagements. You're welcome to reach out to us if you'd like to work out a different arrangement, or we're more than happy to continue assisting as time allows. To expand on the latest instructions from the PR: the point is to stop auditd and run it under ktrace exclusively until you've collected a number of zombies while tracing, then stop it and provide us with the relevant trace and logs. From that, we can gain a better understanding of the event sequencing that's leading to auditd failing to reap the zombies. Thanks, Kyle Evans [0] https://klarasystems.com/