All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: JiangJieHua <jiangjiehua1@huawei.com>
Cc: Paul Moore <paul@paul-moore.com>,
	audit@vger.kernel.org, linux-kernel@vger.kernel.org,
	Eric Paris <eparis@redhat.com>,
	Ricardo Robaina <rrobaina@redhat.com>,
	Florian Westphal <fw@strlen.de>,
	netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
	zhangchangzhong@huawei.com
Subject: Re: [PATCH] audit: fix incomplete NETFILTER_PKT records and return void
Date: Tue, 10 Nov 2026 14:10:38 +0100	[thread overview]
Message-ID: <avMXzjF9hIcTVc9c@chamomile> (raw)
In-Reply-To: <20261110122939.45373-1-jiangjiehua1@huawei.com>

Hi,

On Tue, Nov 10, 2026 at 08:29:39PM +0800, JiangJieHua wrote:
> Commit f19590b07cb6 ("audit: add audit_log_nf_skb helper function") and
> commit 15b0c43aa621 ("audit: include source and destination ports to
> NETFILTER_PKT") introduced audit_log_nf_skb() and its transport header
> parsing.

I guess conntrack is not enough in your scenario. How does your
ruleset look like?

More comments below.

> The helper returned early with -ENOMEM when skb_header_pointer() failed for
> the network header, and the later port parsing did the same for the
> transport header.  Such an early return skips the remaining fields, so the
> NETFILTER_PKT record is emitted with only "mark=" and without the address
> and protocol fields.
> 
> Log the address and protocol once the network header is available, and
> route the error paths through placeholder logging: a missing network header
> logs "saddr=? daddr=? proto=-1", as the pre-refactoring callers did, and a
> transport header that cannot be read where one is expected logs
> "sport=? dport=?".  The same "proto=-1" placeholder is used for an
> unknown bridge ethertype and an unknown nfproto, which previously printed
> "proto=?".
> 
> Validate the IP version and the IPv4 header length, since bridge packets
> can reach the audit hook without the receive path validating them.  Locate
> the transport header from the network header instead of relying on
> skb_transport_offset(), which is not guaranteed to point at the transport
> header.  For IPv4, a non-first fragment or an unreadable transport header
> logs unknown ports; protocols without ports are unaffected.  For IPv6, a
> non-first fragment leaves proto at IPPROTO_FRAGMENT (44) and a negative
> offset from ipv6_skip_exthdr() means the extension header chain cannot be
> parsed; in both cases the transport header is not available, so keep the
> addresses and protocol and do not log ports.
> 
> Both callers ignore the return value (net/netfilter/nft_log.c and
> net/netfilter/xt_AUDIT.c), so make the helper return void instead of
> inventing error codes for a value nobody consumes.
> 
> A packet whose network header cannot be read now logs:
> 
>   before: mark=0x0
>   after:  mark=0x0 saddr=? daddr=? proto=-1
[...]
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 631d6d4a23cf..c5997077a46b 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -2511,8 +2511,8 @@ void audit_log_path_denied(int type, const char *operation)
>  	audit_log_end(ab);
>  }
>  
> -int audit_log_nf_skb(struct audit_buffer *ab,
> -		     const struct sk_buff *skb, u8 nfproto)
> +void audit_log_nf_skb(struct audit_buffer *ab,
> +		      const struct sk_buff *skb, u8 nfproto)
>  {
>  	/* find the IP protocol in the case of NFPROTO_BRIDGE */
>  	if (nfproto == NFPROTO_BRIDGE) {
> @@ -2532,24 +2532,32 @@ int audit_log_nf_skb(struct audit_buffer *ab,
>  	case NFPROTO_IPV4: {
>  		struct iphdr iph;
>  		const struct iphdr *ih;
> +		int thoff;
> +		bool frag;
>  
>  		ih = skb_header_pointer(skb, skb_network_offset(skb),
>  					sizeof(iph), &iph);
>  		if (!ih)
> -			return -ENOMEM;
> +			goto unknown_proto;
> +		if (ih->version != 4 || ih->ihl < 5)
> +			goto unknown_proto;
> +
> +		thoff = skb_network_offset(skb) + ih->ihl * 4;
> +		frag = ntohs(ih->frag_off) & IP_OFFSET;

Are we going to add all these validations everywhere in the code?

So we will have to validate that the IPv4 header is well-formed over
and over again?

  parent reply	other threads:[~2026-11-10 13:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 12:29 [PATCH] audit: fix incomplete NETFILTER_PKT records and return void JiangJieHua
2026-11-10 11:38 ` sashiko-bot
2026-11-10 13:10 ` Pablo Neira Ayuso [this message]
2026-11-10 13:39   ` Florian Westphal
2026-11-10 15:51 ` Bradley Morgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=avMXzjF9hIcTVc9c@chamomile \
    --to=pablo@netfilter.org \
    --cc=audit@vger.kernel.org \
    --cc=coreteam@netfilter.org \
    --cc=eparis@redhat.com \
    --cc=fw@strlen.de \
    --cc=jiangjiehua1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=rrobaina@redhat.com \
    --cc=zhangchangzhong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.