[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-K3oLn++V_zJMjGRXdiPh2qi+Fit6uOh4z4HxuuyCOyog@mail.gmail.com>
Date: Thu, 21 Sep 2023 09:30:05 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Jordan Rife <jrife@...gle.com>, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, netdev@...r.kernel.org, dborkman@...nel.org,
philipp.reisner@...bit.com, lars.ellenberg@...bit.com,
christoph.boehmwalder@...bit.com, axboe@...nel.dk, airlied@...hat.com,
chengyou@...ux.alibaba.com, kaishen@...ux.alibaba.com, jgg@...pe.ca,
leon@...nel.org, bmt@...ich.ibm.com, isdn@...ux-pingi.de, ccaulfie@...hat.com,
teigland@...hat.com, mark@...heh.com, jlbec@...lplan.org,
joseph.qi@...ux.alibaba.com, sfrench@...ba.org, pc@...guebit.com,
lsahlber@...hat.com, sprasad@...rosoft.com, tom@...pey.com,
horms@...ge.net.au, ja@....bg, pablo@...filter.org, kadlec@...filter.org,
fw@...len.de, santosh.shilimkar@...cle.com, stable@...r.kernel.org
Subject: Re: [PATCH net v4 3/3] net: prevent address rewrite in kernel_bind()
On Thu, Sep 21, 2023 at 4:35 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> On Wed, 2023-09-20 at 09:30 -0400, Willem de Bruijn wrote:
> > Jordan Rife wrote:
> > > Similar to the change in commit 0bdf399342c5("net: Avoid address
> > > overwrite in kernel_connect"), BPF hooks run on bind may rewrite the
> > > address passed to kernel_bind(). This change
> > >
> > > 1) Makes a copy of the bind address in kernel_bind() to insulate
> > > callers.
> > > 2) Replaces direct calls to sock->ops->bind() with kernel_bind()
> > >
> > > Link: https://lore.kernel.org/netdev/20230912013332.2048422-1-jrife@google.com/
> > > Fixes: 4fbac77d2d09 ("bpf: Hooks for sys_bind")
> > > Cc: stable@...r.kernel.org
> > > Signed-off-by: Jordan Rife <jrife@...gle.com>
> >
> > Reviewed-by: Willem de Bruijn <willemb@...gle.com>
>
> I fear this is going to cause a few conflicts with other trees. We can
> still take it, but at very least we will need some acks from the
> relevant maintainers.
>
> I *think* it would be easier split this and patch 1/3 in individual
> patches targeting the different trees, hopefully not many additional
> patches will be required. What do you think?
Roughly how many patches would result from this one patch. From the
stat line I count { block/drbd, char/agp, infiniband, isdn, fs/dlm,
fs/ocfs2, fs/smb, netfilter, rds }. That's worst case nine callers
plus the core patch to net/socket.c?
If logistically simpler and you prefer the approach, we can also
revisit Jordan's original approach, which embedded the memcpy inside
the BPF branches.
That has the slight benefit to in-kernel callers that it limits the
cost of the memcpy to cgroup_bpf_enabled. But adds a superfluous
second copy to the more common userspace callers, again at least only
if cgroup_bpf_enabled.
If so, it should at least move the whole logic around those BPF hooks
into helper functions.
Powered by blists - more mailing lists