From: Sascha Hauer <s.hauer@pengutronix.de>
To: Antony Pavlov <antonynpavlov@gmail.com>
Cc: barebox@lists.infradead.org, Oleksij Rempel <o.rempel@pengutronix.de>
Subject: Re: [RFC] sandbox: prevent segfault in tap_alloc()
Date: Fri, 28 Jun 2019 11:04:30 +0200 [thread overview]
Message-ID: <20190628090430.jjpxyr6a7skn76ae@pengutronix.de> (raw)
In-Reply-To: <20190628113226.fb03528ce02c085c039006f4@gmail.com>
On Fri, Jun 28, 2019 at 11:32:26AM +0300, Antony Pavlov wrote:
> On Wed, 26 Jun 2019 09:12:02 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> > Hi Antony,
> >
> > On Wed, Jun 19, 2019 at 01:49:16PM +0300, Antony Pavlov wrote:
> > > Tap network interface initialization in sandbox
> > > barebox leads to segfault under Debian Buster/Sid.
> > >
> > > The problem is that strcpy(dev, ifr.ifr_name) inside
> > > tap_alloc() tries to alter read-only data passed
> > > by tap_probe() and barebox receives SIGSEGV.
> > >
> > > Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
> > > ---
> > > drivers/net/tap.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/tap.c b/drivers/net/tap.c
> > > index 1fbfa085b1..d7e32f4875 100644
> > > --- a/drivers/net/tap.c
> > > +++ b/drivers/net/tap.c
> > > @@ -14,7 +14,7 @@
> > >
> > > struct tap_priv {
> > > int fd;
> > > - char *name;
> > > + char name[128];
> > > };
> > >
> > > static int tap_eth_send(struct eth_device *edev, void *packet, int length)
> > > @@ -65,7 +65,7 @@ static int tap_probe(struct device_d *dev)
> > > int ret = 0;
> > >
> > > priv = xzalloc(sizeof(struct tap_priv));
> > > - priv->name = "barebox";
> > > + strncpy(priv->name, "barebox", sizeof(priv->name));
> > >
> > > priv->fd = tap_alloc(priv->name);
> >
> > Can we change the prototype of tap_alloc() to something like this:
> >
> > int tap_alloc(const char *name, int *fd, char **outname);
> >
> > outname would be an allocated string to be freed by the caller.
>
> There is one problem.
> tap_alloc works in the sandbox "os domain" (glibc *alloc&free etc),
> the caller works in the "barebox domain" (barebox *alloc&free).
Oh, I didn't realize this.
>
> Can we just drop this outname?
> nobody actually use it at the moment.
Yes, let's just drop it.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2019-06-28 9:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 10:49 Antony Pavlov
2019-06-26 7:12 ` Sascha Hauer
2019-06-28 8:32 ` Antony Pavlov
2019-06-28 9:04 ` Sascha Hauer [this message]
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=20190628090430.jjpxyr6a7skn76ae@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=antonynpavlov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=o.rempel@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox