From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D53F52E414 for ; Tue, 25 Aug 2026 00:08:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787616532; cv=none; b=XJ1tDd6FVBr0F81//p8ZUW3pNZmQ0/qw+DqHh5189IfbgLWt5zvlrigyGxp45+tgmqBfJED2Ht4ZBV1JK7yiy/lv52GOhT8KPu9gAiuAN8PX8N9o0k/RKXJgG85DMmzD01U5cj6tzh11uguFbLvcRVxDN9CVep0q5Z3yjUxzdHA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787616532; c=relaxed/simple; bh=zNt8ul5Dug+HD7DqsrQH280x7qPjPH0DLVMLUclrytk=; h=Date:Message-ID:MIME-Version:Content-Type:From:To:Cc:Subject: References:In-Reply-To; b=ixAkYsCg14u7g8uyElq6Kaw7LdVMyFfp36eTgQagLbvWR/CWO/4wu0qTbCkJwouis94Cv2dbLUVndTHFEAwlcXuZSME/L4C6wLrZNT0+Go9CfX40IekJ1sZ3ZJ3NysbLuHjMgCV5or7s+5go+AAIZVtr7zGvwFBE2ym2IUWhXRo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=paul-moore.com; spf=pass smtp.mailfrom=paul-moore.com; dkim=pass (2048-bit key) header.d=paul-moore.com header.i=@paul-moore.com header.b=PdZDM98u; arc=none smtp.client-ip=209.85.222.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=paul-moore.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=paul-moore.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=paul-moore.com header.i=@paul-moore.com header.b="PdZDM98u" Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-92edb12cdf2so272867085a.3 for ; Mon, 24 Aug 2026 17:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1787616529; x=1788221329; darn=vger.kernel.org; h=in-reply-to:references:subject:cc:to:from:content-transfer-encoding :content-type:mime-version:message-id:date:from:to:cc:subject:date :message-id:reply-to:content-type; bh=fZYG0rGmvOndqq2+XvkG4bcHzhwd5RvRGcgzNkG8xqE=; b=PdZDM98umYl/3pFR9//i9uiRywTTocZHnOWXRUQlMdW2GaLzatgB3DQKdtdR33aqUi 0lndTJ6JNR0fU2y56OlhqKnzBU4eh6nsZcrEyjFGAi6+aULTXTmA2t1vx06+PCbwukyc S4CvCnppLdTcDFpwItOz0wlUR+/yx/oq6Zq6HaBieFW9J3lFsMCkYNHtqi6N7iz58vgk sD9Mez24lxVgoDG+QW5wGXnW78V4Gk14H6qFBspjiI634gch77oewkPD9df24XIaR1uB 9UlXBZ/+DQu6H0ft50bpxUbsENLLgl0XJWjtEUQFureDQZvGRc6R4Q84ZxyPYHVS56AG 32gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787616529; x=1788221329; h=in-reply-to:references:subject:cc:to:from:content-transfer-encoding :content-type:mime-version:message-id:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=fZYG0rGmvOndqq2+XvkG4bcHzhwd5RvRGcgzNkG8xqE=; b=cXL1GvBQMbAk/AuNZfE64VkcP+TjVleyOb7DjEiyTJkACRCSJpJUsI5JDiUz7YuNVq 9cC72KvXMUI2uS6Dgjh4u4q2JsSO7olsxWVQxhRLYnHNkvMl9OfDuNJfw1YEzWppiqvM 2DedIawJHsqTBKg6BB2lawbaO5nEfEX7inGAdbzHQ/wXGeuYScA2n2RQyEsDzSKzvzV5 +v+q+XjE0eEARr1sTpTWdk9HQhLP4lnEtSM0/hbsdCIlz3cHA7QbcvJMGOVz6wHOIOmq KH2SZIY+xglb+BEsr+Ur2lmN8EdIyn2yGhJFcHBDYaz+SBoZjuwiYNJWSyZ5gxAeZbz0 r5Mg== X-Forwarded-Encrypted: i=1; AHgh+RqApefx9KeF4c0QjawNWi+YiXJ4GQIytG97hnNFJzzFm5kql79tGppnJo5Q9yx3jmDVs1uUMUaSxVXYmcA=@vger.kernel.org X-Gm-Message-State: AFuF++lUeGJ0vAOG/psnfeRniLXO8RmOBvN3lQFxUkRUjfMZXGWWbGkn SAU7eYJFbY1oB0tjJj5RZFu3he/AiCscAjpf/gs1kE9jGu1mDrzmEl27KDclIuaUIrx/AjHxnX7 Xfe6Itw== X-Gm-Gg: AR+sD10Dw6A2ZJJq+9JWezrkhxIJk9bukagHLnHprcvG+elfm8/9FX5R5sf+H99B0rL 6MJBUXurBRjl9nKNtM4Yke/aQiJU/T1Z0RM/60Uey3lQ4ipNy7YrTrRUwhuKeUFEcphs6pVOwDe VCj1JDobJmXGHB28HMSoq+BFvalgHQYkxNye8gXdiGCCAEBZcQBNmnqOHP86DFUZWdATVIJZPA/ MSKqW609LmRae4vqJaPFHOiCGS41KKLiAqOr/uEH5Okx4icfpaIwfMOglDF7vRL63KwgsKCv3iR vV5UNgThAfFj5ncmY4tB8X6rzgF5eslXCG6TK1oluNiwIqw9nVr+CqhjHEFk8C+NIBsMBbKIpiu pWwbYDspSLHMq9UrmDp9XomsMr62Uej2q4Z3c9NQFUYCow8FRBCgAIJDV1DP+Jiu/dHfiD2E+Tk C+FMc8fPMTbdohiR9/mETmlPucmnM8BiVOQapwX5/2fXlXjtMvJhr4pkYQZG53Jq+Bt6cmRyZXC GLhYJSDhDP8I58Xqbj1FSW1brpVOpA9hQ2s9/6MKoBo X-Received: by 2002:a05:620a:668f:b0:934:97c1:ca5c with SMTP id af79cd13be357-9376f994ecbmr245172785a.16.1787616529334; Mon, 24 Aug 2026 17:08:49 -0700 (PDT) Received: from localhost (pool-71-126-255-178.bstnma.fios.verizon.net. [71.126.255.178]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93749da86eesm615566685a.34.2026.08.24.17.08.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 17:08:48 -0700 (PDT) Date: Mon, 24 Aug 2026 20:08:46 -0400 Message-ID: <552658f244965a3dca8081f0020155e8@paul-moore.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: pstg-pwork:20260824_1800/pstg-lib:20260824_1107/pstg-pwork:20260824_1800 From: Paul Moore To: Bradley Morgan Cc: Eric Paris , Ricardo Robaina , audit@vger.kernel.org, linux-kernel@vger.kernel.org, include@grrlz.net Subject: Re: [PATCH] audit: move the nlmsg_len fixup from __audit_log_end() to send time References: <20260814010153.14488-1-include@grrlz.net> In-Reply-To: <20260814010153.14488-1-include@grrlz.net> On Aug 13, 2026 Bradley Morgan wrote: > > Right now the auditd breakage (nlmsg_len gets set to the payload > length instead of the full message length) is applied when the record > is queued, in __audit_log_end(). That is why > kauditd_send_multicast_skb() has to deep copy every record and then > undo the length on the copy, just so the multicast group still sees a > standard netlink message. > > So flip it: finalize the header with the standard full length at > queue time, and apply the auditd length at send time in > kauditd_send_queue(), right before the unicast. Records stay standard > netlink messages the whole time they sit in the queues, and the > multicast copy stops needing its own fixup. The copy itself stays, > because the rewrite still lands in the data region the listeners > already hold. > > auditd sees the same bytes as before: the fixup is computed from > skb->len and that does not change between queueing and sending, so > records that come back around through the retry and hold queues get > the same value again. Reply and rule list skbs are built with > nlmsg_put() and go out on their own paths, none of that is touched. > > This came out of reviewing Ricardo's "use copied skb length" patch, > where I suggested moving the fixup as the more interesting cleanup. > > Reviewed-by: Ricardo Robaina > Tested-by: Ricardo Robaina > Signed-off-by: Bradley Morgan > Link: https://lore.kernel.org/r/20260810125726.775689-2-rrobaina@redhat.com > --- > kernel/audit.c | 30 +++++++++++++----------------- > 1 file changed, 13 insertions(+), 17 deletions(-) > > diff --git a/kernel/audit.c b/kernel/audit.c > index 9412af9144bc..bcfed6e3678e 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -802,6 +802,12 @@ static int kauditd_send_queue(struct sock *sk, u32 portid, > if (skb_hook) > (*skb_hook)(skb); > > + /* > + * auditd wants nlmsg_len to be the payload length, not the > + * full length, so break it here at send time. > + */ > + nlmsg_hdr(skb)->nlmsg_len = skb->len - NLMSG_HDRLEN; One of the reasons we set the length in __audit_log_end() is so that we only do it once, plus the multicast fixup. In this patch we still set the length in __audit_log_end() as well as potentially multiple times in kauditd_send_queue(). This patch does drop the multicast fixup, but it isn't as clean a solution conceptually as the current code in my opinion. Ultimately, in this patch we still have at least two length calculations with the potential for additional unnecessary calculations/assignments if we need to loop through kauditd_send_queue() multiple times. The existing code is capped at two calculations/assignments. I appreciate the time you've put into this, but I think the existing code is the better option at this point in time. > /* can we send to anyone via unicast? */ > if (!sk) { > if (err_hook) -- paul-moore.com