Re: [PATCH v5 2/2] audit: include source and destination ports to NETFILTER_PKT

On Fri, Nov 7, 2025 at 7:46 PM Paul Moore <[email protected]> wrote:
>
> On Nov  6, 2025 Ricardo Robaina <[email protected]> wrote:
> >
> > NETFILTER_PKT records show both source and destination
> > addresses, in addition to the associated networking protocol.
> > However, it lacks the ports information, which is often
> > valuable for troubleshooting.
> >
> > This patch adds both source and destination port numbers,
> > 'sport' and 'dport' respectively, to TCP, UDP, UDP-Lite and
> > SCTP-related NETFILTER_PKT records.
> >
> >  $ TESTS="netfilter_pkt" make -e test &> /dev/null
> >  $ ausearch -i -ts recent |grep NETFILTER_PKT
> >  type=NETFILTER_PKT ... proto=icmp
> >  type=NETFILTER_PKT ... proto=ipv6-icmp
> >  type=NETFILTER_PKT ... proto=udp sport=46333 dport=42424
> >  type=NETFILTER_PKT ... proto=udp sport=35953 dport=42424
> >  type=NETFILTER_PKT ... proto=tcp sport=50314 dport=42424
> >  type=NETFILTER_PKT ... proto=tcp sport=57346 dport=42424
> >
> > Link: https://github.com/linux-audit/audit-kernel/issues/162
> >
> > Signed-off-by: Ricardo Robaina <[email protected]>
> > Acked-by: Florian Westphal <[email protected]>
> > ---
> >  kernel/audit.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++---
> >  1 file changed, 79 insertions(+), 4 deletions(-)
>
> This looks fine to me, although it may change a bit based on the
> discussion around patch 1/2.  However, two things I wanted to comment
> on in this patch:
>
> - Please try to stick to an 80 char line width for audit code.  There are
> obvious exceptions like printf-esque strings, etc. but the
> skb_header_pointer() calls in this patch could be easily split into
> multiple lines, each under 80 chars.
>

Thanks for the feedback! I'll make sure to follow this guideline from now on.

> - This isn't a general comment, but in this particular case it would be
> nice to move the protocol header variables into their associated switch
> case (see what I did in patch 1/2).
>

Nice, thanks for the tip! I wasn't sure which style to use, so I
decided to use the classic one. However, I do prefer having the
protocol header variables within their associated switch case, too.

> --
> paul-moore.com
>