From: Marek Lindner <mareklindner@neomailbox.ch>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Cc: Sven Eckelmann <sven@narfation.org>
Subject: Re: [PATCH 3/3] alfred: properly initialize stack buffer before sending over unix socket
Date: Sat, 22 Jan 2022 14:06:31 +0100 [thread overview]
Message-ID: <55198855.o2EDfbc6B2@rousseau> (raw)
In-Reply-To: <18671636.mmkZKWO0Lj@sven-l14>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
On Saturday, 22 January 2022 09:03:12 CET Sven Eckelmann wrote:
> > The struct alfred_change_interface_v0 -> ifaces[IFNAMSIZ * 16] may be
> > written to but not fully initialized. The interface name may be much
> > shorter than the buffer holding it. Same applies struct
> > alfred_change_bat_iface_v0 -> bat_iface[IFNAMSIZ] but to a lesser extent
> > because the buffer is smaller.
>
> But strncpy writes n bytes (second parameter of n). So the name + n-
> strlen(name) 0-bytes. I thought I've corrected my earlier statement about
> strncpy but maybe I forgot it. So strlcpy will take care of always writing a
> single 0-byte at the end of a non-0-length buffer - but is not writing more
> than 1x 0-byte (so half of the buffer might be uninitialised). strncpy will
> fill the remaining bytes with 0 but might end up writing NO 0-bytes when
> the buffer was already full.
Thanks for highlighting this difference between strncpy() and strlcpy(). I see
your point.
> But in your status patch, not all 16 name entries were written. So it leaks
> things from the stack and the receiver might parse things which are not
> actually written by the sender. And your code was not explicitly making sure
> that the buffer ends with a 0-byte.
The server status patch iterates over the list of interfaces and performs
individual strncpy() calls, so that strncpy() can't initialize the entire
buffer unless there are 16 interfaces to begin with. Ok!
Then drop this patch.
Kind regards,
Marek Lindner
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-01-22 13:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-12 21:02 alfred: allow startup without network interface Marek Lindner
2022-01-12 21:05 ` [PATCH 1/3] alfred: move interface check into helper function Marek Lindner
2022-01-12 21:05 ` [PATCH 2/3] alfred: Allow operating without any interface specified Marek Lindner
2022-01-12 21:05 ` [PATCH 3/3] alfred: properly initialize stack buffer before sending over unix socket Marek Lindner
2022-01-21 15:34 ` Sven Eckelmann
2022-01-22 0:41 ` Marek Lindner
2022-01-22 8:03 ` Sven Eckelmann
2022-01-22 13:06 ` Marek Lindner [this message]
2022-01-12 21:11 ` alfred: allow startup without network interface Marek Lindner
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=55198855.o2EDfbc6B2@rousseau \
--to=mareklindner@neomailbox.ch \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=sven@narfation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox