All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: lvs-devel@vger.kernel.org, lvs-users@linuxvirtualserver.org,
	Simon Horman <horms@verge.net.au>,
	Ryan O'Hara <rohara@redhat.com>,
	brouer@redhat.com
Subject: Re: [PATCH] libipvs: fix some buffer sizes
Date: Tue, 29 May 2018 16:06:55 +0200	[thread overview]
Message-ID: <20180529160655.673cd177@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.20.1805252144090.3447@ja.home.ssi.bg>

On Fri, 25 May 2018 21:48:31 +0300 (EEST)
Julian Anastasov <ja@ssi.bg> wrote:

> 	Hello,
> 
> On Fri, 25 May 2018, Jesper Dangaard Brouer wrote:
> 
> > 
> > On Thu, 24 May 2018 23:37:45 +0300 Julian Anastasov <ja@ssi.bg> wrote:
> >   
> > > Size or length? Here is the answer:
> > > 
> > > - IP_VS_SCHEDNAME_MAXLEN and IP_VS_IFNAME_MAXLEN are sizes
> > > because they are used in kernel structures exported to user
> > > space for the old setsockopt interface. We can not change
> > > these structures in the kernel.
> > > 
> > > - IP_VS_PENAME_MAXLEN and IP_VS_PEDATA_MAXLEN are max lengths
> > > because they are not exported to the old interface.
> > > 
> > > As result:
> > > - buffers should have space for NUL terminator
> > > - strncpy should use sizeof(buffer) - 1 as max length
> > > 
> > > As we change the libipvs structures, their users should be
> > > recompiled.
> > > 
> > > Signed-off-by: Julian Anastasov <ja@ssi.bg>  
> > 
> > This all looks fine to me.  I'll give other people a little time to
> > review and ACK, before I apply this.  
> 
> 	Thanks!

Applied:
 https://git.kernel.org/pub/scm/utils/kernel/ipvsadm/ipvsadm.git/commit/?id=5cd1778489c52
 
> > (To Julian) did you find this by manual review, or did you use some tool
> > to find these?  
> 
> 	As you noticed the kernel patch, all started with
> the syzkaller report, then by manual review...

I added a note to the commit desc, pointing to the kernel commit,
gracefully reminding future distro backporters that the kernel side
also have issues in this area ;-)

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

  reply	other threads:[~2018-05-29 14:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-24 20:37 [PATCH] libipvs: fix some buffer sizes Julian Anastasov
2018-05-25  7:29 ` Jesper Dangaard Brouer
2018-05-25  9:34   ` Simon Horman
2018-05-25 18:48   ` Julian Anastasov
2018-05-29 14:06     ` Jesper Dangaard Brouer [this message]
2018-05-29 18:56       ` Julian Anastasov

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=20180529160655.673cd177@redhat.com \
    --to=brouer@redhat.com \
    --cc=horms@verge.net.au \
    --cc=ja@ssi.bg \
    --cc=lvs-devel@vger.kernel.org \
    --cc=lvs-users@linuxvirtualserver.org \
    --cc=rohara@redhat.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.