All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Fernando Fernandez Mancera <fmancera@suse.de>
Cc: netdev@vger.kernel.org, tgraf@infradead.org, horms@kernel.org,
	pabeni@redhat.com, edumazet@google.com, dsahern@kernel.org,
	davem@davemloft.net
Subject: Re: [PATCH 1/2 net-next v2] ipv4: validate IPV4_DEVCONF attributes properly
Date: Mon, 2 Mar 2026 16:18:24 -0800	[thread overview]
Message-ID: <20260302161824.0cb19417@kernel.org> (raw)
In-Reply-To: <a038563b-05f2-4e11-9cd4-ad6374d379aa@suse.de>

On Mon, 2 Mar 2026 09:35:06 +0100 Fernando Fernandez Mancera wrote:
> >> Please note that MEDIUM_ID is defined as NLA_U32 too because currently
> >> its usage through netlink is broken for its valid value -1. Modifying
> >> the type to NLA_S32 would break existing users of set/get netlink
> >> operation.  
> > 
> > Say more? The policy type not matching the accessor used by the kernel
> > is probably fine in this case (since there's a common accessor used for
> > all attrs). If it helps the policy, we can use a different type.
> 
> The problem is not only not matching the accessor.. the problem is that 
> while it was not validated if users were using NLA_U32 as indicated by 
> the original implementation (see blamed commit), this would break them.
> 
> Is it one option to set the type to NLA_S32 and wait to see if someone 
> complains? I am not sure how many people might be using it considering 
> the type is wrong.

Sorry, I'm not connecting the dots.

	[IPV4_DEVCONF_MEDIUM_ID]	= { .type = NLA_U32 },
vs 
	[IPV4_DEVCONF_MEDIUM_ID]	= { .type = NLA_S32 },

makes absolutely _no_ difference. For bare types with no ranges 
the validation will only check the attr is 4B which is identical 
for both. 

For S32 you can add a range, however, the NLA_POLICY_RANGE() takes 
two signed 16b values. So a range of -1 .. x is completely fine.

  reply	other threads:[~2026-03-03  0:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-26 13:39 [PATCH 1/2 net-next v2] ipv4: validate IPV4_DEVCONF attributes properly Fernando Fernandez Mancera
2026-02-26 13:39 ` [PATCH 2/2 net-next v2] ipv4: bump rt_genid when a relevant devconf value changes through netlink Fernando Fernandez Mancera
2026-02-28 18:45   ` Jakub Kicinski
2026-03-02  8:27     ` Fernando Fernandez Mancera
2026-03-03  0:19       ` Jakub Kicinski
2026-03-03 11:06         ` Fernando Fernandez Mancera
2026-02-28 18:43 ` [PATCH 1/2 net-next v2] ipv4: validate IPV4_DEVCONF attributes properly Jakub Kicinski
2026-03-02  8:35   ` Fernando Fernandez Mancera
2026-03-03  0:18     ` Jakub Kicinski [this message]
2026-03-03 11:04       ` Fernando Fernandez Mancera

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=20260302161824.0cb19417@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=fmancera@suse.de \
    --cc=horms@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=tgraf@infradead.org \
    /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.