netdev - Re: [PATCH v2 net-next] Ipvlan should return an error when an address is already in use.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170609171310.GA2766@templeofstupid.com>
Date:   Fri, 9 Jun 2017 10:13:10 -0700
From:   Krister Johansen <kjlx@...pleofstupid.com>
To:     David Miller <davem@...emloft.net>
Cc:     kjlx@...pleofstupid.com, maheshb@...gle.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2 net-next] Ipvlan should return an error when an
 address is already in use.

On Fri, Jun 09, 2017 at 12:26:46PM -0400, David Miller wrote:
> From: Krister Johansen <kjlx@...pleofstupid.com>
> Date: Thu, 8 Jun 2017 13:12:14 -0700
> 
> > The ipvlan code already knows how to detect when a duplicate address is
> > about to be assigned to an ipvlan device.  However, that failure is not
> > propogated outward and leads to a silent failure.
> > 
> > Introduce a validation step at ip address creation time and allow device
> > drivers to register to validate the incoming ip addresses.  The ipvlan
> > code is the first consumer.  If it detects an address in use, we can
> > return an error to the user before beginning to commit the new ifa in
> > the networking code.
> > 
> > This can be especially useful if it is necessary to provision many
> > ipvlans in containers.  The provisioning software (or operator) can use
> > this to detect situations where an ip address is unexpectedly in use.
> > 
> > Signed-off-by: Krister Johansen <kjlx@...pleofstupid.com>
> 
> Ok, applied, thank you.

Thanks, did this look otherwise alright?  I was a little nervous about
dropping and re-acquiring the rcu_read_lock_bh() in net/ipv6/addrconf.c
around line 975, but in the current design holding rcu_read_lock_bh()
causes the in_softirq() check in the validator (and the add/remove
ipvlan code itself) to return NOTIFY_DONE immediately.

AFAICT, the rcu_read_lock was to protect the idev.  I changed that to
get subsequently released in the outbound path.  I was also unsure if
it's safe to call in6_dev_put from a bh context.

Thanks,

-K