All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1] tools: fix usage of strncpy
@ 2020-06-08  7:28 Olaf Hering
  2020-06-08  8:00 ` Olaf Hering
  0 siblings, 1 reply; 9+ messages in thread
From: Olaf Hering @ 2020-06-08  7:28 UTC (permalink / raw)
  To: xen-devel; +Cc: Anthony PERARD, Olaf Hering, Ian Jackson, Wei Liu

In case of truncation no trailing zero will be added to the target
string. Reduce the amount of bytes to copy by one to make sure a
trailing zero always exists.

In file included from /usr/include/string.h:495,
                 from libxl_internal.h:38,
                 from libxl_utils.c:20:
In function 'strncpy',
    inlined from 'libxl__prepare_sockaddr_un' at libxl_utils.c:1262:5:
/usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Signed-off-by: Olaf Hering <olaf@aepfle.de>
---

gcc may not detect the off-by-one error in libxl__prepare_sockaddr_un, fix the strncpy usage anyway.

 tools/libvchan/vchan-socket-proxy.c | 8 ++++----
 tools/libxl/libxl_utils.c           | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c
index 13700c5d67..b312f05ca7 100644
--- a/tools/libvchan/vchan-socket-proxy.c
+++ b/tools/libvchan/vchan-socket-proxy.c
@@ -140,7 +140,7 @@ static int set_nonblocking(int fd, int nonblocking) {
 static int connect_socket(const char *path_or_fd) {
     int fd;
     char *endptr;
-    struct sockaddr_un addr;
+    struct sockaddr_un addr = {};
 
     fd = strtoll(path_or_fd, &endptr, 0);
     if (*endptr == '\0') {
@@ -153,7 +153,7 @@ static int connect_socket(const char *path_or_fd) {
         return -1;
 
     addr.sun_family = AF_UNIX;
-    strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path));
+    strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path) - 1);
     if (connect(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) {
         close(fd);
         return -1;
@@ -167,7 +167,7 @@ static int connect_socket(const char *path_or_fd) {
 static int listen_socket(const char *path_or_fd) {
     int fd;
     char *endptr;
-    struct sockaddr_un addr;
+    struct sockaddr_un addr = {};
 
     fd = strtoll(path_or_fd, &endptr, 0);
     if (*endptr == '\0') {
@@ -180,7 +180,7 @@ static int listen_socket(const char *path_or_fd) {
         return -1;
 
     addr.sun_family = AF_UNIX;
-    strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path));
+    strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path) - 1);
     if (bind(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) {
         close(fd);
         return -1;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index f360f5e228..83592e829d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -1259,7 +1259,7 @@ int libxl__prepare_sockaddr_un(libxl__gc *gc,
     }
     memset(un, 0, sizeof(struct sockaddr_un));
     un->sun_family = AF_UNIX;
-    strncpy(un->sun_path, path, sizeof(un->sun_path));
+    strncpy(un->sun_path, path, sizeof(un->sun_path) - 1);
     return 0;
 }
 


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] tools: fix usage of strncpy
  2020-06-08  7:28 [PATCH v1] tools: fix usage of strncpy Olaf Hering
@ 2020-06-08  8:00 ` Olaf Hering
  2020-06-08 11:01   ` Ian Jackson
  0 siblings, 1 reply; 9+ messages in thread
From: Olaf Hering @ 2020-06-08  8:00 UTC (permalink / raw)
  To: xen-devel; +Cc: Anthony PERARD, Ian Jackson, Wei Liu

[-- Attachment #1: Type: text/plain, Size: 186 bytes --]

Am Mon,  8 Jun 2020 09:28:54 +0200
schrieb Olaf Hering <olaf@aepfle.de>:

> off-by-one error in libxl__prepare_sockaddr_un

There is none, I had read the code backwards...

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] tools: fix usage of strncpy
  2020-06-08  8:00 ` Olaf Hering
@ 2020-06-08 11:01   ` Ian Jackson
  2020-06-08 12:43     ` Jason Andryuk
  0 siblings, 1 reply; 9+ messages in thread
From: Ian Jackson @ 2020-06-08 11:01 UTC (permalink / raw)
  To: Olaf Hering; +Cc: Anthony PERARD, xen-devel, Wei Liu

Olaf Hering writes ("Re: [PATCH v1] tools: fix usage of strncpy"):
> Am Mon,  8 Jun 2020 09:28:54 +0200
> schrieb Olaf Hering <olaf@aepfle.de>:
> > off-by-one error in libxl__prepare_sockaddr_un
> 
> There is none, I had read the code backwards...

I have just had the same thoughts but in the opposite order.  That is
at first I thought this was not a problem, but now I think there is.

There are some kernel interfaces where a fixed-size buffer is
provided, and the kernel will tolerate a null-terminated string, but
will in any case not read beyond the end of the buffer.  Anything
involving IFNAMSIZ comes to mind.

But I think sun_path is not one of those.  The manpage I have here
says that to be portable you must null-terminate sun_path.  I know
that there are some implementations where it is possible to pass a
longer path, effectively treating sun_path as a trailing vla.

Looking at your diff, its effect seems to be to ensure
null-termination by truncating overlong paths.

I think the right approach is to return an error, not to silently
truncate.

Ian.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] tools: fix usage of strncpy
  2020-06-08 11:01   ` Ian Jackson
@ 2020-06-08 12:43     ` Jason Andryuk
  2020-06-08 14:11       ` Olaf Hering
  0 siblings, 1 reply; 9+ messages in thread
From: Jason Andryuk @ 2020-06-08 12:43 UTC (permalink / raw)
  To: Ian Jackson; +Cc: Anthony PERARD, xen-devel, Olaf Hering, Wei Liu

On Mon, Jun 8, 2020 at 7:03 AM Ian Jackson <ian.jackson@citrix.com> wrote:
>
> Olaf Hering writes ("Re: [PATCH v1] tools: fix usage of strncpy"):
> > Am Mon,  8 Jun 2020 09:28:54 +0200
> > schrieb Olaf Hering <olaf@aepfle.de>:
> > > off-by-one error in libxl__prepare_sockaddr_un
> >
> > There is none, I had read the code backwards...
>
> I have just had the same thoughts but in the opposite order.  That is
> at first I thought this was not a problem, but now I think there is.
>
> There are some kernel interfaces where a fixed-size buffer is
> provided, and the kernel will tolerate a null-terminated string, but
> will in any case not read beyond the end of the buffer.  Anything
> involving IFNAMSIZ comes to mind.
>
> But I think sun_path is not one of those.  The manpage I have here
> says that to be portable you must null-terminate sun_path.  I know
> that there are some implementations where it is possible to pass a
> longer path, effectively treating sun_path as a trailing vla.
>
> Looking at your diff, its effect seems to be to ensure
> null-termination by truncating overlong paths.
>
> I think the right approach is to return an error, not to silently
> truncate.

I added a length check in this patch:

https://lore.kernel.org/xen-devel/20200525024955.225415-2-jandryuk@gmail.com/

Regards,
Jason


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] tools: fix usage of strncpy
  2020-06-08 12:43     ` Jason Andryuk
@ 2020-06-08 14:11       ` Olaf Hering
  2020-06-09 12:33         ` Jason Andryuk
  2020-06-09 16:35         ` Rich Persaud
  0 siblings, 2 replies; 9+ messages in thread
From: Olaf Hering @ 2020-06-08 14:11 UTC (permalink / raw)
  To: Jason Andryuk; +Cc: Anthony PERARD, Ian Jackson, Wei Liu, xen-devel

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

Am Mon, 8 Jun 2020 08:43:50 -0400
schrieb Jason Andryuk <jandryuk@gmail.com>:

> I added a length check in this patch:

gcc will not recognize such runtime checks and will (most likely) complain about the strncpy usage anyway, just as it does now in libxl__prepare_sockaddr_un. While the usage in libxl__prepare_sockaddr_un is fatal due to -Werror, libvchan is apparently built without -Werror.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] tools: fix usage of strncpy
  2020-06-08 14:11       ` Olaf Hering
@ 2020-06-09 12:33         ` Jason Andryuk
  2020-06-09 13:16           ` Olaf Hering
  2020-06-09 16:35         ` Rich Persaud
  1 sibling, 1 reply; 9+ messages in thread
From: Jason Andryuk @ 2020-06-09 12:33 UTC (permalink / raw)
  To: Olaf Hering; +Cc: Anthony PERARD, Ian Jackson, Wei Liu, xen-devel

On Mon, Jun 8, 2020 at 10:11 AM Olaf Hering <olaf@aepfle.de> wrote:
>
> Am Mon, 8 Jun 2020 08:43:50 -0400
> schrieb Jason Andryuk <jandryuk@gmail.com>:
>
> > I added a length check in this patch:
>
> gcc will not recognize such runtime checks and will (most likely) complain about the strncpy usage anyway, just as it does now in libxl__prepare_sockaddr_un. While the usage in libxl__prepare_sockaddr_un is fatal due to -Werror, libvchan is apparently built without -Werror.

gcc complaining about strncpy after the length check is unfortunate.
Do you know if gcc would complain if strcpy is used?  It would be okay
since we just checked the length.

What version of gcc are you using?  I was using 9.x and it didn't warn
from what I can remember.

Regards,
Jason


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] tools: fix usage of strncpy
  2020-06-09 12:33         ` Jason Andryuk
@ 2020-06-09 13:16           ` Olaf Hering
  0 siblings, 0 replies; 9+ messages in thread
From: Olaf Hering @ 2020-06-09 13:16 UTC (permalink / raw)
  To: Jason Andryuk; +Cc: Anthony PERARD, Ian Jackson, Wei Liu, xen-devel

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Am Tue, 9 Jun 2020 08:33:12 -0400
schrieb Jason Andryuk <jandryuk@gmail.com>:

> What version of gcc are you using?  I was using 9.x and it didn't warn from what I can remember.

This is gcc10 from current Tumbleweed. For libxl strcpy will certainly work because the length check is done prior the copying of data.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] tools: fix usage of strncpy
  2020-06-08 14:11       ` Olaf Hering
  2020-06-09 12:33         ` Jason Andryuk
@ 2020-06-09 16:35         ` Rich Persaud
  2020-06-09 16:41           ` Olaf Hering
  1 sibling, 1 reply; 9+ messages in thread
From: Rich Persaud @ 2020-06-09 16:35 UTC (permalink / raw)
  To: Olaf Hering
  Cc: Wei Liu, Jason Andryuk, Marek Marczykowski-Górecki,
	xen-devel, Anthony PERARD, Ian Jackson

On Jun 8, 2020, at 10:12, Olaf Hering <olaf@aepfle.de> wrote:
> 
> Am Mon, 8 Jun 2020 08:43:50 -0400
> schrieb Jason Andryuk <jandryuk@gmail.com>:
> 
>> I added a length check in this patch:
> 
> gcc will not recognize such runtime checks and will (most likely) complain about the strncpy usage anyway, just as it does now in libxl__prepare_sockaddr_un. While the usage in libxl__prepare_sockaddr_un is fatal due to -Werror, libvchan is apparently built without -Werror.
> 
> Olaf

Is there any reason not to take a patch that builds libvchan with -Werror?

Rich

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] tools: fix usage of strncpy
  2020-06-09 16:35         ` Rich Persaud
@ 2020-06-09 16:41           ` Olaf Hering
  0 siblings, 0 replies; 9+ messages in thread
From: Olaf Hering @ 2020-06-09 16:41 UTC (permalink / raw)
  To: Rich Persaud
  Cc: Wei Liu, Jason Andryuk, Marek Marczykowski-Górecki,
	xen-devel, Anthony PERARD, Ian Jackson

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

Am Tue, 9 Jun 2020 12:35:51 -0400
schrieb Rich Persaud <persaur@gmail.com>:

> Is there any reason not to take a patch that builds libvchan with -Werror?

The per-subdirectory settings of -Werror should probably become a global -Werror. Someone has to step up and explore that path.
Bonus points if -Werror could be disabled via configure.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-06-09 16:41 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-08  7:28 [PATCH v1] tools: fix usage of strncpy Olaf Hering
2020-06-08  8:00 ` Olaf Hering
2020-06-08 11:01   ` Ian Jackson
2020-06-08 12:43     ` Jason Andryuk
2020-06-08 14:11       ` Olaf Hering
2020-06-09 12:33         ` Jason Andryuk
2020-06-09 13:16           ` Olaf Hering
2020-06-09 16:35         ` Rich Persaud
2020-06-09 16:41           ` Olaf Hering

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.