Re: "ss -p" segfaults (updated to 4.2)

[Stephen Hemminger]

Applied, and did some editing on commit msg
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "ss -p" segfaults (updated to 4.2)

[Willy Tarreau]

On Mon, Oct 12, 2015 at 09:50:19AM -0700, Stephen Hemminger wrote:
> Applied, and did some editing on commit msg

Thank you Stephen!

Willy

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "ss -p" segfaults (updated to 4.2)

[j...@openmailbox.org]

Hi Willy,

It seems fine to me.
You may reword the commit message at will.

Thx,
Jose

On 2015-10-06 11:09, Willy Tarreau wrote:
> Hi guys,
> 
> I've updated Jose's patch to make it slightly simpler (eg: calloc instead
> of malloc+memset), and ported it to 4.2.0 which requires it as well, and
> attached it to this e-mail.
> 
> I can confirm that with this patch 4.1.1 doesn't segfault on me anymore.
> The commit message should be reworked I guess though everything's in it
> and I didn't want to modify his description.
> 
> Can it be merged as-is or should I reword the commit message and reference
> Jose as the fix reporter ? We should not let this bug live forever.
> 
> Thanks,
> Willy
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "ss -p" segfaults (updated to 4.2)

[Willy Tarreau]

Hi guys,

I've updated Jose's patch to make it slightly simpler (eg: calloc instead
of malloc+memset), and ported it to 4.2.0 which requires it as well, and
attached it to this e-mail.

I can confirm that with this patch 4.1.1 doesn't segfault on me anymore.
The commit message should be reworked I guess though everything's in it
and I didn't want to modify his description.

Can it be merged as-is or should I reword the commit message and reference
Jose as the fix reporter ? We should not let this bug live forever.

Thanks,
Willy

>From 618028d6c5bfa4fb9898f2ec1ab5483e6f5392d4 Mon Sep 17 00:00:00 2001
From: "j...@openmailbox.org" <j...@openmailbox.org>
Date: Tue, 21 Jul 2015 10:54:05 +0100
Subject: "ss -p" segfaults

Patch for 4.2.0

Essentially all that is needed to get rid of this issue is the
addition of:

memset(u, 0, sizeof(*u));

after:

if (!(u = malloc(sizeof(*u
break;

Also patched some other situations (strcpy and sprintf uses) that
potentially produce the same results.

Signed-off-by: Jose P Santos <j...@openmailbox.org>

[ wt: made Jose's patch slightly simpler, all credits to him for the diag ]
Signed-off-by: Willy Tarreau <w...@1wt.eu>
---
 misc/ss.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/misc/ss.c b/misc/ss.c
index 2f34962..8b0d606 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -457,7 +457,9 @@ static void user_ent_hash_build(void)
 
user_ent_hash_build_init = 1;
 
-   strcpy(name, root);
+   strncpy(name, root, sizeof(name)-1);
+   name[sizeof(name)-1] = 0;
+
if (strlen(name) == 0 || name[strlen(name)-1] != '/')
strcat(name, "/");
 
@@ -481,7 +483,7 @@ static void user_ent_hash_build(void)
if (getpidcon(pid, _context) != 0)
pid_context = strdup(no_ctx);
 
-   sprintf(name + nameoff, "%d/fd/", pid);
+   snprintf(name + nameoff, sizeof(name) - nameoff, "%d/fd/", pid);
pos = strlen(name);
if ((dir1 = opendir(name)) == NULL) {
free(pid_context);
@@ -502,7 +504,7 @@ static void user_ent_hash_build(void)
if (sscanf(d1->d_name, "%d%c", , ) != 1)
continue;
 
-   sprintf(name+pos, "%d", fd);
+   snprintf(name+pos, sizeof(name) - pos, "%d", fd);
 
link_len = readlink(name, lnk, sizeof(lnk)-1);
if (link_len == -1)
@@ -2736,7 +2738,7 @@ static int unix_show(struct filter *f)
struct sockstat *u, **insp;
int flags;
 
-   if (!(u = malloc(sizeof(*u
+   if (!(u = calloc(1, sizeof(*u
break;
u->name = NULL;
u->peer_name = NULL;
@@ -3086,11 +3088,13 @@ static int netlink_show_one(struct filter *f,
strncpy(procname, "kernel", 6);
} else if (pid > 0) {
FILE *fp;
-   sprintf(procname, "%s/%d/stat",
+   snprintf(procname, sizeof(procname), "%s/%d/stat",
getenv("PROC_ROOT") ? : "/proc", pid);
if ((fp = fopen(procname, "r")) != NULL) {
if (fscanf(fp, "%*d (%[^)])", procname) == 1) {
-   sprintf(procname+strlen(procname), 
"/%d", pid);
+   snprintf(procname+strlen(procname),
+   
sizeof(procname)-strlen(procname),
+   "/%d", pid);
done = 1;
}
fclose(fp);
-- 
1.7.12.1

Re: ss -p segfaults

[j...@openmailbox.org]

Patch for 4.1.1.

Essentially all that is needed to get rid of this issue is the
addition of:

memset(u, 0, sizeof(*u));

after:

if (!(u = malloc(sizeof(*u
break;

Also patched some other situations (strcpy and sprintf uses) that
potentially produce the same results.

Signed-off-by: Jose P Santos j...@openmailbox.org

--- iproute2-4.1.1/misc/ss.c.orig   2015-07-06 22:57:34.0 +0100
+++ iproute2-4.1.1/misc/ss.c2015-07-21 10:26:45.0 +0100
@@ -456,7 +456,10 @@ static void user_ent_hash_build(void)

user_ent_hash_build_init = 1;

-   strcpy(name, root);
+   /* Avoid buffer overrun if input size from PROC_ROOT  name */
+   memset(name, 0, sizeof(name));
+   strncpy(name, root, sizeof(name)-2);
+
if (strlen(name) == 0 || name[strlen(name)-1] != '/')
strcat(name, /);

@@ -480,7 +483,7 @@ static void user_ent_hash_build(void)
if (getpidcon(pid, pid_context) != 0)
pid_context = strdup(no_ctx);

-   sprintf(name + nameoff, %d/fd/, pid);
+   snprintf(name + nameoff, sizeof(name) - nameoff, %d/fd/, pid);
pos = strlen(name);
if ((dir1 = opendir(name)) == NULL)
continue;
@@ -499,7 +502,7 @@ static void user_ent_hash_build(void)
if (sscanf(d1-d_name, %d%c, fd, crap) != 1)
continue;

-   sprintf(name+pos, %d, fd);
+   snprintf(name+pos, sizeof(name) - pos, %d, fd);

link_len = readlink(name, lnk, sizeof(lnk)-1);
if (link_len == -1)
@@ -2722,6 +2725,11 @@ static int unix_show(struct filter *f)
if (!(u = malloc(sizeof(*u
break;

+   /* Zero initialization of 'u' struct avoids a segfault
+* when freeing memory 'free(name)' at 'unix_list_free()'.
+*/
+   memset(u, 0, sizeof(*u));
+
if (sscanf(buf, %x: %x %x %x %x %x %d %s,
   u-rport, u-rq, u-wq, flags, u-type,
   u-state, u-ino, name)  8)
@@ -3064,11 +3072,13 @@ static int netlink_show_one(struct filte
strncpy(procname, kernel, 6);
} else if (pid  0) {
FILE *fp;
-   sprintf(procname, %s/%d/stat,
+   snprintf(procname, sizeof(procname), %s/%d/stat,
getenv(PROC_ROOT) ? : /proc, pid);
if ((fp = fopen(procname, r)) != NULL) {
if (fscanf(fp, %*d (%[^)]), procname) == 1) {
-   sprintf(procname+strlen(procname), 
/%d, pid);
+   snprintf(procname+strlen(procname),
+   
sizeof(procname)-strlen(procname),
+   /%d, pid);
done = 1;
}
fclose(fp);



On 2015-07-20 20:09, Stephen Hemminger wrote:
 Patches are always appreciated and this looks like a real bug.
 But before I can accept it there are a couple of small
 changes needed.
 
 1. There is no need to check for NULL when calling free().
Glibc free is documented to accept NULL as a valid request
and do nothing.
 
 2. Please add a Signed-off-by: line with a real name.
Signed-off-by has legal meaning for the Developer's Certificate of Origin
see kernel documentation if you need more explaination.
 
 3. Although what you found is important, giving a full paragraph
of personal comment about it is not required. The point is software
should read like one source independent of who the authors are.
Your comment is basically just justifying using strncpy.
 
 4. Rather than strncpy() which has issues with maximal sized strings
consider using strlcpy() instead.
 
 5. Iproute2 uses kernel identation and style, consider running checkpatch
on your changes.
 
 Please fixup and resubmit to netdev.
 
 


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ss -p segfaults

[Andreas Schwab]

j...@openmailbox.org j...@openmailbox.org writes:

 - free(p-process);
 - free(p-process_ctx);
 - free(p-socket_ctx);
 + if (p-process)
 + free(p-process);
 + if (p-process_ctx)
 + free(p-process_ctx);
 + if (p-socket_ctx)
 + free(p-socket_ctx);

free(NULL) is a no-op.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ss -p segfaults

[j...@openmailbox.org]

Please find attached one simple patch for the code 4.1.0/4.1.1.

Essentially all that is needed to get rid of this issue is the
addition of:

memset(u, 0, sizeof(*u));

after:

if (!(u = malloc(sizeof(*u
break;

During the analysis of this issue I also found some other situations
(strcpy and sprintf uses) that potentially produce the same results.

Corrections are also added, all with full comments.

Regards,
Jose Santos


--- iproute2-4.1.1-orig/misc/ss.c   2015-07-06 22:57:34.0 +0100
+++ iproute2-4.1.1/misc/ss.c2015-07-19 12:16:25.0 +0100
@@ -428,9 +428,12 @@
while (cnt != USER_ENT_HASH_SIZE) {
p = user_ent_hash[cnt];
while (p) {
-   free(p-process);
-   free(p-process_ctx);
-   free(p-socket_ctx);
+   if (p-process)
+   free(p-process);
+   if (p-process_ctx)
+   free(p-process_ctx);
+   if (p-socket_ctx)
+   free(p-socket_ctx);
p_next = p-next;
free(p);
p = p_next;
@@ -456,7 +459,21 @@

user_ent_hash_build_init = 1;

-   strcpy(name, root);
+   /* strcpy is really dangerous!  in this case if we're going to
+  copy an  unknown input  size from  getenv(PROC_ROOT) to a
+  fixed size buffer name[1024] we're going to get troubles.
+  If the size of a manipulated  PROC_ROOT  size of name we
+  will have a buffer overrun smashing the stack,  overwriting
+  other local variables and/or return address, etc... */
+
+   memset(name, 0, sizeof(name));
+
+   strncpy(name, root, 512);
+   /* Chose this value ^^^ (maybe too large) just to avoid buffer
+  overflow  if sizeof getenv(PROC_ROOT)  sizeof(name)  and
+  to allow the  name composition that follows below to fit in
+  the remaining space. */
+
if (strlen(name) == 0 || name[strlen(name)-1] != '/')
strcat(name, /);

@@ -480,7 +497,7 @@
if (getpidcon(pid, pid_context) != 0)
pid_context = strdup(no_ctx);

-   sprintf(name + nameoff, %d/fd/, pid);
+   snprintf(name + nameoff, sizeof(name) - nameoff, %d/fd/, pid);
pos = strlen(name);
if ((dir1 = opendir(name)) == NULL)
continue;
@@ -499,7 +516,7 @@
if (sscanf(d1-d_name, %d%c, fd, crap) != 1)
continue;

-   sprintf(name+pos, %d, fd);
+   snprintf(name+pos, sizeof(name) - pos, %d, fd);

link_len = readlink(name, lnk, sizeof(lnk)-1);
if (link_len == -1)
@@ -529,9 +546,16 @@
}
user_ent_add(ino, p, pid, fd,
pid_context, sock_context);
-   free(sock_context);
-   }
-   free(pid_context);
+   /* memory was  allocated  conditionally so
+  freeing it should go the same way (even
+  though the actual  code implies that in
+  this case it will always be allocated). */
+   if (sock_context)
+   free(sock_context);
+   }
+   /* same as above */
+   if (pid_context)
+   free(pid_context);
closedir(dir1);
}
closedir(dir);
@@ -2722,6 +2746,13 @@
if (!(u = malloc(sizeof(*u
break;

+   /* The following memset of 'u' struct is crucial to avoid a 
segfault
+  when freeing memory 'free(name)' at 'unix_list_free()'.  In 
fact,
+  without this  'initialization', testing 'if (name)'  at line 
2513
+  will most likely return true even if 'name' isn't allocated. 
*/
+
+   memset(u, 0, sizeof(*u));
+
if (sscanf(buf, %x: %x %x %x %x %x %d %s,
   u-rport, u-rq, u-wq, flags, u-type,
   u-state, u-ino, name)  8)
@@ -3064,11 +3095,12 @@
strncpy(procname, kernel, 6);
} else if (pid  0) {
FILE *fp;
-   sprintf(procname, %s/%d/stat,
+   snprintf(procname, sizeof(procname), %s/%d/stat,
getenv(PROC_ROOT) ? : /proc, pid);
if ((fp = fopen(procname, r)) != NULL) {
if (fscanf(fp, %*d (%[^)]), procname) == 1) {
-   sprintf(procname+strlen(procname), 
/%d, pid);
+   

Re: ss -p segfaults

[Marc Dietrich]

Am Donnerstag, 16. Juli 2015, 01:22:38 schrieb Vadim Kochan:
 On Wed, Jul 15, 2015 at 09:57:51PM +0300, Vadim Kochan wrote:
  On Wed, Jul 15, 2015 at 06:52:49PM +, Rustad, Mark D wrote:
On Jul 15, 2015, at 9:49 AM, Rustad, Mark D mark.d.rus...@intel.com 
wrote:
On Jul 15, 2015, at 8:12 AM, Vadim Kochan vadi...@gmail.com wrote:
Would you please check this fix ?

diff --git a/misc/ss.c b/misc/ss.c
index 03f92fa..3a826e4 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -683,8 +683,8 @@ static inline void sock_addr_set_str(inet_prefix
*prefix, char **ptr)

static inline char *sock_addr_get_str(const inet_prefix *prefix)
{
-char *tmp ;
-memcpy(tmp, prefix-data, sizeof(char *));
+char *tmp;
+memcpy(tmp, prefix-data[0], sizeof(char *));

   return tmp;

}

That surely is not a fix! The destination of the memcpy is the address
of an uninitialized stack variable! Both versions are equally bad.  
   I probably over-reacted, but using memcpy to access a pointer in this
   way is just ugly. For one thing, it circumvents any sanity-checking
   that the compiler can do. And changing the prefix-data to
   prefix-data[0] should be exactly the same thing and therefore should
   not fix anything. Anyway, never mind that.
   
   Looking at more of the code, it looks to me like the the string pointer
   in data can sometimes point to a literal string instead of allocated
   memory when proc is in use. Free would not be happy with that. Look at
   the use of variable peer in function unix_stats_print. 
  Yes that right, I am already looking on this ...
  
   --
   Mark Rustad, Networking Division, Intel Corporation
 
 I did partially revert of the buggy commit and it does not crash, but I will
 do more testing, and after will send the patch and will try to prepare some
 test scripts for ss.
 
 The crash appears only if to dump processes info from /proc, which might
 be caused that netlink stats returned error, probably by wrong request
 (not supported attribute or flag ?).

the reason it uses proc for me is my self compiled (and trimmed) kernel which 
disabled all *_diag modules which seem to be required by ss. I didn't know 
this. On the other hand, I managed to find a bug this way :-)

Marc



signature.asc
Description: This is a digitally signed message part.

Re: ss -p segfaults

[Rustad, Mark D]

 On Jul 15, 2015, at 8:12 AM, Vadim Kochan vadi...@gmail.com wrote:
 Would you please check this fix ?
 
 diff --git a/misc/ss.c b/misc/ss.c
 index 03f92fa..3a826e4 100644
 --- a/misc/ss.c
 +++ b/misc/ss.c
 @@ -683,8 +683,8 @@ static inline void sock_addr_set_str(inet_prefix *prefix, 
 char **ptr)
 
 static inline char *sock_addr_get_str(const inet_prefix *prefix)
 {
 -char *tmp ;
 -memcpy(tmp, prefix-data, sizeof(char *));
 +char *tmp;
 +memcpy(tmp, prefix-data[0], sizeof(char *));
 return tmp;
 }

That surely is not a fix! The destination of the memcpy is the address of an 
uninitialized stack variable! Both versions are equally bad.

--
Mark Rustad, Networking Division, Intel Corporation



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ss -p segfaults

[Rustad, Mark D]

 On Jul 15, 2015, at 9:49 AM, Rustad, Mark D mark.d.rus...@intel.com wrote:
 
 On Jul 15, 2015, at 8:12 AM, Vadim Kochan vadi...@gmail.com wrote:
 Would you please check this fix ?
 
 diff --git a/misc/ss.c b/misc/ss.c
 index 03f92fa..3a826e4 100644
 --- a/misc/ss.c
 +++ b/misc/ss.c
 @@ -683,8 +683,8 @@ static inline void sock_addr_set_str(inet_prefix 
 *prefix, char **ptr)
 
 static inline char *sock_addr_get_str(const inet_prefix *prefix)
 {
 -char *tmp ;
 -memcpy(tmp, prefix-data, sizeof(char *));
 +char *tmp;
 +memcpy(tmp, prefix-data[0], sizeof(char *));
return tmp;
 }
 
 That surely is not a fix! The destination of the memcpy is the address of an 
 uninitialized stack variable! Both versions are equally bad.

I probably over-reacted, but using memcpy to access a pointer in this way is 
just ugly. For one thing, it circumvents any sanity-checking that the compiler 
can do. And changing the prefix-data to prefix-data[0] should be exactly the 
same thing and therefore should not fix anything. Anyway, never mind that.

Looking at more of the code, it looks to me like the the string pointer in data 
can sometimes point to a literal string instead of allocated memory when proc 
is in use. Free would not be happy with that. Look at the use of variable peer 
in function unix_stats_print.

--
Mark Rustad, Networking Division, Intel Corporation



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ss -p segfaults

[Vadim Kochan]

On Wed, Jul 15, 2015 at 06:52:49PM +, Rustad, Mark D wrote:
  On Jul 15, 2015, at 9:49 AM, Rustad, Mark D mark.d.rus...@intel.com wrote:
  
  On Jul 15, 2015, at 8:12 AM, Vadim Kochan vadi...@gmail.com wrote:
  Would you please check this fix ?
  
  diff --git a/misc/ss.c b/misc/ss.c
  index 03f92fa..3a826e4 100644
  --- a/misc/ss.c
  +++ b/misc/ss.c
  @@ -683,8 +683,8 @@ static inline void sock_addr_set_str(inet_prefix 
  *prefix, char **ptr)
  
  static inline char *sock_addr_get_str(const inet_prefix *prefix)
  {
  -char *tmp ;
  -memcpy(tmp, prefix-data, sizeof(char *));
  +char *tmp;
  +memcpy(tmp, prefix-data[0], sizeof(char *));
 return tmp;
  }
  
  That surely is not a fix! The destination of the memcpy is the address of 
  an uninitialized stack variable! Both versions are equally bad.
 
 I probably over-reacted, but using memcpy to access a pointer in this way is 
 just ugly. For one thing, it circumvents any sanity-checking that the 
 compiler can do. And changing the prefix-data to prefix-data[0] should be 
 exactly the same thing and therefore should not fix anything. Anyway, never 
 mind that.
 
 Looking at more of the code, it looks to me like the the string pointer in 
 data can sometimes point to a literal string instead of allocated memory when 
 proc is in use. Free would not be happy with that. Look at the use of 
 variable peer in function unix_stats_print.
 
Yes that right, I am already looking on this ...
 --
 Mark Rustad, Networking Division, Intel Corporation
 
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ss -p segfaults

[Vadim Kochan]

On Wed, Jul 15, 2015 at 09:57:51PM +0300, Vadim Kochan wrote:
 On Wed, Jul 15, 2015 at 06:52:49PM +, Rustad, Mark D wrote:
   On Jul 15, 2015, at 9:49 AM, Rustad, Mark D mark.d.rus...@intel.com 
   wrote:
   
   On Jul 15, 2015, at 8:12 AM, Vadim Kochan vadi...@gmail.com wrote:
   Would you please check this fix ?
   
   diff --git a/misc/ss.c b/misc/ss.c
   index 03f92fa..3a826e4 100644
   --- a/misc/ss.c
   +++ b/misc/ss.c
   @@ -683,8 +683,8 @@ static inline void sock_addr_set_str(inet_prefix 
   *prefix, char **ptr)
   
   static inline char *sock_addr_get_str(const inet_prefix *prefix)
   {
   -char *tmp ;
   -memcpy(tmp, prefix-data, sizeof(char *));
   +char *tmp;
   +memcpy(tmp, prefix-data[0], sizeof(char *));
  return tmp;
   }
   
   That surely is not a fix! The destination of the memcpy is the address of 
   an uninitialized stack variable! Both versions are equally bad.
  
  I probably over-reacted, but using memcpy to access a pointer in this way 
  is just ugly. For one thing, it circumvents any sanity-checking that the 
  compiler can do. And changing the prefix-data to prefix-data[0] should 
  be exactly the same thing and therefore should not fix anything. Anyway, 
  never mind that.
  
  Looking at more of the code, it looks to me like the the string pointer in 
  data can sometimes point to a literal string instead of allocated memory 
  when proc is in use. Free would not be happy with that. Look at the use of 
  variable peer in function unix_stats_print.
  
 Yes that right, I am already looking on this ...
  --
  Mark Rustad, Networking Division, Intel Corporation
  

I did partially revert of the buggy commit and it does not crash, but I will do
more testing, and after will send the patch and will try to prepare some
test scripts for ss.

The crash appears only if to dump processes info from /proc, which might
be caused that netlink stats returned error, probably by wrong request
(not supported attribute or flag ?).
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ss -p segfaults

[Marc Dietrich]

Hi,

ss -p segfaults here with some kind of memory corruption:

*** Error in `/work/iproute2/misc/ss': free(): invalid pointer: 
0x00623000 ***
=== Backtrace: =
/lib64/libc.so.6(+0x71c6d)[0x77885c6d]
/lib64/libc.so.6(+0x771be)[0x7788b1be]
/lib64/libc.so.6(+0x7799b)[0x7788b99b]
/work/iproute2/misc/ss[0x403de1]
/work/iproute2/misc/ss[0x408247]
/work/iproute2/misc/ss[0x403295]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x77834790]
/work/iproute2/misc/ss[0x4037f9]
=== Memory map: 
0040-00416000 r-xp  00:33 4207305
/work/iproute2/misc/ss
00616000-00617000 r--p 00016000 00:33 4207305
/work/iproute2/misc/ss
00617000-0061b000 rw-p 00017000 00:33 4207305
/work/iproute2/misc/ss
0061b000-0065f000 rw-p  00:00 0  
[heap]
76f6d000-76f83000 r-xp  00:21 16154175   
/lib64/libgcc_s.so.1
76f83000-77182000 ---p 00016000 00:21 16154175   
/lib64/libgcc_s.so.1
77182000-77183000 r--p 00015000 00:21 16154175   
/lib64/libgcc_s.so.1
77183000-77184000 rw-p 00016000 00:21 16154175   
/lib64/libgcc_s.so.1
77184000-7719c000 r-xp  00:21 16694826   
/lib64/libpthread-2.21.so
7719c000-7739b000 ---p 00018000 00:21 16694826   
/lib64/libpthread-2.21.so
7739b000-7739c000 r--p 00017000 00:21 16694826   
/lib64/libpthread-2.21.so
7739c000-7739d000 rw-p 00018000 00:21 16694826   
/lib64/libpthread-2.21.so
7739d000-773a1000 rw-p  00:00 0 
773a1000-773a4000 r-xp  00:21 16694804   
/lib64/libdl-2.21.so
773a4000-775a3000 ---p 3000 00:21 16694804   
/lib64/libdl-2.21.so
775a3000-775a4000 r--p 2000 00:21 16694804   
/lib64/libdl-2.21.so
775a4000-775a5000 rw-p 3000 00:21 16694804   
/lib64/libdl-2.21.so
775a5000-77613000 r-xp  00:21 16153198   
/usr/lib64/libpcre.so.1.2.5
77613000-77812000 ---p 0006e000 00:21 16153198   
/usr/lib64/libpcre.so.1.2.5
77812000-77813000 r--p 0006d000 00:21 16153198   
/usr/lib64/libpcre.so.1.2.5
77813000-77814000 rw-p 0006e000 00:21 16153198   
/usr/lib64/libpcre.so.1.2.5
77814000-779ad000 r-xp  00:21 16694798   
/lib64/libc-2.21.so
779ad000-77bac000 ---p 00199000 00:21 16694798   
/lib64/libc-2.21.so
77bac000-77bb1000 r--p 00198000 00:21 16694798   
/lib64/libc-2.21.so
77bb1000-77bb3000 rw-p 0019d000 00:21 16694798   
/lib64/libc-2.21.so
77bb3000-77bb7000 rw-p  00:00 0 
77bb7000-77bd8000 r-xp  00:21 16155991   
/lib64/libselinux.so.1
77bd8000-77dd7000 ---p 00021000 00:21 16155991   
/lib64/libselinux.so.1
77dd7000-77dd8000 r--p 0002 00:21 16155991   
/lib64/libselinux.so.1
77dd8000-77dd9000 rw-p 00021000 00:21 16155991   
/lib64/libselinux.so.1
77dd9000-77ddb000 rw-p  00:00 0 
77ddb000-77dfc000 r-xp  00:21 16694791   
/lib64/ld-2.21.so
77fb5000-77fba000 rw-p  00:00 0 
77ff5000-77ff8000 rw-p  00:00 0 
77ff8000-77ffa000 r--p  00:00 0  
[vvar]
77ffa000-77ffc000 r-xp  00:00 0  
[vdso]
77ffc000-77ffd000 r--p 00021000 00:21 16694791   
/lib64/ld-2.21.so
77ffd000-77ffe000 rw-p 00022000 00:21 16694791   
/lib64/ld-2.21.so
77ffe000-77fff000 rw-p  00:00 0 
7ffdd000-7000 rw-p  00:00 0  
[stack]
ff60-ff601000 r-xp  00:00 0  
[vsyscall]

Program received signal SIGABRT, Aborted.
0x77847638 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: zypper install libgcc_s1-
debuginfo-5.1.1+r224716-1.2.x86_64 libpcre1-debuginfo-8.37-1.18.x86_64 
libselinux1-debuginfo-2.3-5.18.x86_64
(gdb) bt full
#0  0x77847638 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x77848a1a in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x77885c72 in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#3  0x7788b1be in malloc_printerr () from /lib64/libc.so.6
No symbol table info available.
#4  0x7788b99b in _int_free () from /lib64/libc.so.6
No symbol table info available.
#5  0x00403de1 in unix_list_free (list=0x6251a0, list@entry=0x645b50) 
at ss.c:2516
s = 0x623010

Re: ss -p segfaults

[Vadim Kochan]

On Wed, Jul 15, 2015 at 04:09:03PM +0200, Marc Dietrich wrote:
 Hi,
 
 ss -p segfaults here with some kind of memory corruption:
 
 *** Error in `/work/iproute2/misc/ss': free(): invalid pointer: 
 0x00623000 ***
 === Backtrace: =
 /lib64/libc.so.6(+0x71c6d)[0x77885c6d]
 /lib64/libc.so.6(+0x771be)[0x7788b1be]
 /lib64/libc.so.6(+0x7799b)[0x7788b99b]
 /work/iproute2/misc/ss[0x403de1]
 /work/iproute2/misc/ss[0x408247]
 /work/iproute2/misc/ss[0x403295]
 /lib64/libc.so.6(__libc_start_main+0xf0)[0x77834790]
 /work/iproute2/misc/ss[0x4037f9]
 === Memory map: 
 0040-00416000 r-xp  00:33 4207305
 /work/iproute2/misc/ss
 00616000-00617000 r--p 00016000 00:33 4207305
 /work/iproute2/misc/ss
 00617000-0061b000 rw-p 00017000 00:33 4207305
 /work/iproute2/misc/ss
 0061b000-0065f000 rw-p  00:00 0  
 [heap]
 76f6d000-76f83000 r-xp  00:21 16154175   
 /lib64/libgcc_s.so.1
 76f83000-77182000 ---p 00016000 00:21 16154175   
 /lib64/libgcc_s.so.1
 77182000-77183000 r--p 00015000 00:21 16154175   
 /lib64/libgcc_s.so.1
 77183000-77184000 rw-p 00016000 00:21 16154175   
 /lib64/libgcc_s.so.1
 77184000-7719c000 r-xp  00:21 16694826   
 /lib64/libpthread-2.21.so
 7719c000-7739b000 ---p 00018000 00:21 16694826   
 /lib64/libpthread-2.21.so
 7739b000-7739c000 r--p 00017000 00:21 16694826   
 /lib64/libpthread-2.21.so
 7739c000-7739d000 rw-p 00018000 00:21 16694826   
 /lib64/libpthread-2.21.so
 7739d000-773a1000 rw-p  00:00 0 
 773a1000-773a4000 r-xp  00:21 16694804   
 /lib64/libdl-2.21.so
 773a4000-775a3000 ---p 3000 00:21 16694804   
 /lib64/libdl-2.21.so
 775a3000-775a4000 r--p 2000 00:21 16694804   
 /lib64/libdl-2.21.so
 775a4000-775a5000 rw-p 3000 00:21 16694804   
 /lib64/libdl-2.21.so
 775a5000-77613000 r-xp  00:21 16153198   
 /usr/lib64/libpcre.so.1.2.5
 77613000-77812000 ---p 0006e000 00:21 16153198   
 /usr/lib64/libpcre.so.1.2.5
 77812000-77813000 r--p 0006d000 00:21 16153198   
 /usr/lib64/libpcre.so.1.2.5
 77813000-77814000 rw-p 0006e000 00:21 16153198   
 /usr/lib64/libpcre.so.1.2.5
 77814000-779ad000 r-xp  00:21 16694798   
 /lib64/libc-2.21.so
 779ad000-77bac000 ---p 00199000 00:21 16694798   
 /lib64/libc-2.21.so
 77bac000-77bb1000 r--p 00198000 00:21 16694798   
 /lib64/libc-2.21.so
 77bb1000-77bb3000 rw-p 0019d000 00:21 16694798   
 /lib64/libc-2.21.so
 77bb3000-77bb7000 rw-p  00:00 0 
 77bb7000-77bd8000 r-xp  00:21 16155991   
 /lib64/libselinux.so.1
 77bd8000-77dd7000 ---p 00021000 00:21 16155991   
 /lib64/libselinux.so.1
 77dd7000-77dd8000 r--p 0002 00:21 16155991   
 /lib64/libselinux.so.1
 77dd8000-77dd9000 rw-p 00021000 00:21 16155991   
 /lib64/libselinux.so.1
 77dd9000-77ddb000 rw-p  00:00 0 
 77ddb000-77dfc000 r-xp  00:21 16694791   
 /lib64/ld-2.21.so
 77fb5000-77fba000 rw-p  00:00 0 
 77ff5000-77ff8000 rw-p  00:00 0 
 77ff8000-77ffa000 r--p  00:00 0  
 [vvar]
 77ffa000-77ffc000 r-xp  00:00 0  
 [vdso]
 77ffc000-77ffd000 r--p 00021000 00:21 16694791   
 /lib64/ld-2.21.so
 77ffd000-77ffe000 rw-p 00022000 00:21 16694791   
 /lib64/ld-2.21.so
 77ffe000-77fff000 rw-p  00:00 0 
 7ffdd000-7000 rw-p  00:00 0  
 [stack]
 ff60-ff601000 r-xp  00:00 0  
 [vsyscall]
 
 Program received signal SIGABRT, Aborted.
 0x77847638 in raise () from /lib64/libc.so.6
 Missing separate debuginfos, use: zypper install libgcc_s1-
 debuginfo-5.1.1+r224716-1.2.x86_64 libpcre1-debuginfo-8.37-1.18.x86_64 
 libselinux1-debuginfo-2.3-5.18.x86_64
 (gdb) bt full
 #0  0x77847638 in raise () from /lib64/libc.so.6
 No symbol table info available.
 #1  0x77848a1a in abort () from /lib64/libc.so.6
 No symbol table info available.
 #2  0x77885c72 in __libc_message () from /lib64/libc.so.6
 No symbol table info available.
 #3  0x7788b1be in malloc_printerr () from /lib64/libc.so.6
 No symbol table info available.
 #4  0x7788b99b in _int_free

Re: ss -p segfaults

[Vadim Kochan]

On Wed, Jul 15, 2015 at 04:09:03PM +0200, Marc Dietrich wrote:
 Hi,
 
 ss -p segfaults here with some kind of memory corruption:
 
 *** Error in `/work/iproute2/misc/ss': free(): invalid pointer: 
 0x00623000 ***
 === Backtrace: =
 /lib64/libc.so.6(+0x71c6d)[0x77885c6d]
 /lib64/libc.so.6(+0x771be)[0x7788b1be]
 /lib64/libc.so.6(+0x7799b)[0x7788b99b]
 /work/iproute2/misc/ss[0x403de1]
 /work/iproute2/misc/ss[0x408247]
 /work/iproute2/misc/ss[0x403295]
 /lib64/libc.so.6(__libc_start_main+0xf0)[0x77834790]
 /work/iproute2/misc/ss[0x4037f9]
 === Memory map: 
 0040-00416000 r-xp  00:33 4207305
 /work/iproute2/misc/ss
 00616000-00617000 r--p 00016000 00:33 4207305
 /work/iproute2/misc/ss
 00617000-0061b000 rw-p 00017000 00:33 4207305
 /work/iproute2/misc/ss
 0061b000-0065f000 rw-p  00:00 0  
 [heap]
 76f6d000-76f83000 r-xp  00:21 16154175   
 /lib64/libgcc_s.so.1
 76f83000-77182000 ---p 00016000 00:21 16154175   
 /lib64/libgcc_s.so.1
 77182000-77183000 r--p 00015000 00:21 16154175   
 /lib64/libgcc_s.so.1
 77183000-77184000 rw-p 00016000 00:21 16154175   
 /lib64/libgcc_s.so.1
 77184000-7719c000 r-xp  00:21 16694826   
 /lib64/libpthread-2.21.so
 7719c000-7739b000 ---p 00018000 00:21 16694826   
 /lib64/libpthread-2.21.so
 7739b000-7739c000 r--p 00017000 00:21 16694826   
 /lib64/libpthread-2.21.so
 7739c000-7739d000 rw-p 00018000 00:21 16694826   
 /lib64/libpthread-2.21.so
 7739d000-773a1000 rw-p  00:00 0 
 773a1000-773a4000 r-xp  00:21 16694804   
 /lib64/libdl-2.21.so
 773a4000-775a3000 ---p 3000 00:21 16694804   
 /lib64/libdl-2.21.so
 775a3000-775a4000 r--p 2000 00:21 16694804   
 /lib64/libdl-2.21.so
 775a4000-775a5000 rw-p 3000 00:21 16694804   
 /lib64/libdl-2.21.so
 775a5000-77613000 r-xp  00:21 16153198   
 /usr/lib64/libpcre.so.1.2.5
 77613000-77812000 ---p 0006e000 00:21 16153198   
 /usr/lib64/libpcre.so.1.2.5
 77812000-77813000 r--p 0006d000 00:21 16153198   
 /usr/lib64/libpcre.so.1.2.5
 77813000-77814000 rw-p 0006e000 00:21 16153198   
 /usr/lib64/libpcre.so.1.2.5
 77814000-779ad000 r-xp  00:21 16694798   
 /lib64/libc-2.21.so
 779ad000-77bac000 ---p 00199000 00:21 16694798   
 /lib64/libc-2.21.so
 77bac000-77bb1000 r--p 00198000 00:21 16694798   
 /lib64/libc-2.21.so
 77bb1000-77bb3000 rw-p 0019d000 00:21 16694798   
 /lib64/libc-2.21.so
 77bb3000-77bb7000 rw-p  00:00 0 
 77bb7000-77bd8000 r-xp  00:21 16155991   
 /lib64/libselinux.so.1
 77bd8000-77dd7000 ---p 00021000 00:21 16155991   
 /lib64/libselinux.so.1
 77dd7000-77dd8000 r--p 0002 00:21 16155991   
 /lib64/libselinux.so.1
 77dd8000-77dd9000 rw-p 00021000 00:21 16155991   
 /lib64/libselinux.so.1
 77dd9000-77ddb000 rw-p  00:00 0 
 77ddb000-77dfc000 r-xp  00:21 16694791   
 /lib64/ld-2.21.so
 77fb5000-77fba000 rw-p  00:00 0 
 77ff5000-77ff8000 rw-p  00:00 0 
 77ff8000-77ffa000 r--p  00:00 0  
 [vvar]
 77ffa000-77ffc000 r-xp  00:00 0  
 [vdso]
 77ffc000-77ffd000 r--p 00021000 00:21 16694791   
 /lib64/ld-2.21.so
 77ffd000-77ffe000 rw-p 00022000 00:21 16694791   
 /lib64/ld-2.21.so
 77ffe000-77fff000 rw-p  00:00 0 
 7ffdd000-7000 rw-p  00:00 0  
 [stack]
 ff60-ff601000 r-xp  00:00 0  
 [vsyscall]
 
 Program received signal SIGABRT, Aborted.
 0x77847638 in raise () from /lib64/libc.so.6
 Missing separate debuginfos, use: zypper install libgcc_s1-
 debuginfo-5.1.1+r224716-1.2.x86_64 libpcre1-debuginfo-8.37-1.18.x86_64 
 libselinux1-debuginfo-2.3-5.18.x86_64
 (gdb) bt full
 #0  0x77847638 in raise () from /lib64/libc.so.6
 No symbol table info available.
 #1  0x77848a1a in abort () from /lib64/libc.so.6
 No symbol table info available.
 #2  0x77885c72 in __libc_message () from /lib64/libc.so.6
 No symbol table info available.
 #3  0x7788b1be in malloc_printerr () from /lib64/libc.so.6
 No symbol table info available.
 #4  0x7788b99b in _int_free