Bug#1018061: pads: segfault at 3a ip
Hi Bernhard, Well that explains that then, I didn't change anything to pin to the patched version. In that case it was fixed and I broke it. Hopefully the patch will be part of a future release and it'll be peachy again. Thanks for explaining what happened. -- Tim McConnell On Fri, 2023-03-24 at 11:52 +0100, Bernhard Übelacker wrote: > Am 23.03.23 um 17:38 schrieb Tim McConnell: > > Bernhard, > > Just cause I said it was fixed this happens to show up in > > journalctl: > > systemd-coredump[3614]: Process 1704 (pads) of user 0 dumped core. > > > > Module > > libsystemd.so.0 from deb systemd-252.5-2.amd64 > > Stack trace of > > thread 1704: > > #0 > > 0x5600f24f6954 print_arp_asset_screen (pads + 0x9954) > > #1 > > 0x5600f24f66f0 print_arp_asset (pads + 0x96f0) > > #2 > > 0x7fdc7fdb54f6 n/a (libpcap.so.0.8 + 0x84f6) > > #3 > > 0x7fdc7fdb58ec n/a (libpcap.so.0.8 + 0x88ec) > > #4 > > 0x7fdc7fdbcd1d pcap_loop (libpcap.so.0.8 + 0xfd1d) > > #5 > > 0x5600f24efe5b main_pads (pads + 0x2e5b) > > #6 > > 0x5600f24ef47b main (pads + 0x247b) > > #7 > > 0x7fdc7fbec18a __libc_start_call_main (libc.so.6 + 0x2718a) > > #8 > > 0x7fdc7fbec245 __libc_start_main_impl (libc.so.6 + 0x27245) > > #9 > > 0x5600f24ef4b1 _start (pads + 0x24b1) > > ELF object > > binary > > architecture: AMD x86-64 > > Mar 04 14:31:02 DebianTim systemd[1]: > > systemd-coredump@0-3613-0.service: Deactivated successfully. > > > > Well I thought it was fixed :-( > > > Hello Time, > are you sure that your rebuilt package is still in place? > The offsets in your new backtrace are exactly the same as > in the email from 8 Feb 2023. > > We have not changed the version of the rebuilt package. > Additionally built with "-b". > Then with a "apt dist-upgrade" always > the Debian version gets reinstalled. > > Sorry for not mentioning that extra care has to be taken > to hold the rebuilt package version in place. > > Kind regards, > Bernhard
Bug#1018061: pads: segfault at 3a ip
Am 23.03.23 um 17:38 schrieb Tim McConnell: Bernhard, Just cause I said it was fixed this happens to show up in journalctl: systemd-coredump[3614]: Process 1704 (pads) of user 0 dumped core. Module libsystemd.so.0 from deb systemd-252.5-2.amd64 Stack trace of thread 1704: #0 0x5600f24f6954 print_arp_asset_screen (pads + 0x9954) #1 0x5600f24f66f0 print_arp_asset (pads + 0x96f0) #2 0x7fdc7fdb54f6 n/a (libpcap.so.0.8 + 0x84f6) #3 0x7fdc7fdb58ec n/a (libpcap.so.0.8 + 0x88ec) #4 0x7fdc7fdbcd1d pcap_loop (libpcap.so.0.8 + 0xfd1d) #5 0x5600f24efe5b main_pads (pads + 0x2e5b) #6 0x5600f24ef47b main (pads + 0x247b) #7 0x7fdc7fbec18a __libc_start_call_main (libc.so.6 + 0x2718a) #8 0x7fdc7fbec245 __libc_start_main_impl (libc.so.6 + 0x27245) #9 0x5600f24ef4b1 _start (pads + 0x24b1) ELF object binary architecture: AMD x86-64 Mar 04 14:31:02 DebianTim systemd[1]: systemd-coredump@0-3613-0.service: Deactivated successfully. Well I thought it was fixed :-( Hello Time, are you sure that your rebuilt package is still in place? The offsets in your new backtrace are exactly the same as in the email from 8 Feb 2023. We have not changed the version of the rebuilt package. Additionally built with "-b". Then with a "apt dist-upgrade" always the Debian version gets reinstalled. Sorry for not mentioning that extra care has to be taken to hold the rebuilt package version in place. Kind regards, Bernhard
Bug#1018061: pads: segfault at 3a ip
Bernhard, Just cause I said it was fixed this happens to show up in journalctl: systemd-coredump[3614]: Process 1704 (pads) of user 0 dumped core. Module libsystemd.so.0 from deb systemd-252.5-2.amd64 Stack trace of thread 1704: #0 0x5600f24f6954 print_arp_asset_screen (pads + 0x9954) #1 0x5600f24f66f0 print_arp_asset (pads + 0x96f0) #2 0x7fdc7fdb54f6 n/a (libpcap.so.0.8 + 0x84f6) #3 0x7fdc7fdb58ec n/a (libpcap.so.0.8 + 0x88ec) #4 0x7fdc7fdbcd1d pcap_loop (libpcap.so.0.8 + 0xfd1d) #5 0x5600f24efe5b main_pads (pads + 0x2e5b) #6 0x5600f24ef47b main (pads + 0x247b) #7 0x7fdc7fbec18a __libc_start_call_main (libc.so.6 + 0x2718a) #8 0x7fdc7fbec245 __libc_start_main_impl (libc.so.6 + 0x27245) #9 0x5600f24ef4b1 _start (pads + 0x24b1) ELF object binary architecture: AMD x86-64 Mar 04 14:31:02 DebianTim systemd[1]: systemd-coredump@0-3613-0.service: Deactivated successfully. Well I thought it was fixed :-( -- Tim McConnell On Wed, 2023-03-22 at 09:55 +0100, Bernhard Übelacker wrote: > control: tags -1 +patch > > > Hello Tim, > nice to hear it helps. Therefore adding the patch tag. > > Kind regards, > Bernhard > > > > Am 21.03.23 um 17:53 schrieb Tim McConnell: > > Hi Bernhard, > > I believe the patch has fixed the issue. I haven't seen any > > messages > > about psad since installing the patch. > > Thanks so much for the fix & patience with me. > > >
Bug#1018061: pads: segfault at 3a ip
control: tags -1 +patch Hello Tim, nice to hear it helps. Therefore adding the patch tag. Kind regards, Bernhard Am 21.03.23 um 17:53 schrieb Tim McConnell: Hi Bernhard, I believe the patch has fixed the issue. I haven't seen any messages about psad since installing the patch. Thanks so much for the fix & patience with me.
Bug#1018061: pads: segfault at 3a ip
Hi Bernhard,
I believe the patch has fixed the issue. I haven't seen any messages
about psad since installing the patch.
Thanks so much for the fix & patience with me.
--
Tim McConnell
On Wed, 2023-03-15 at 12:10 +0100, Bernhard Übelacker wrote:
> Am 26.02.23 um 16:47 schrieb Tim McConnell:
>
> > Hi Bernhard,
> > The delay is fine, I'm sure it takes a minute to figure it out ;-)
> > and
> > no I didn't have anything other than defaults for GDB set. I'm not
> > a
> > programmer so I don't know all the tricks to GDB or when is best
> > to
> > use them. With that said, how would I go about installing /testing
> > the
> > patch you provide? I'm happy to test it out for you, I just need
> > the
> > knowledge of how to.
> > Thanks!
> >
>
>
> Hello Tim,
> if you are fine with installing a bunch of build dependencies
> you could use following steps to rebuild the package with the patch.
>
> As root:
> # apt build-dep pads
>
> As user:
> $ mkdir -p source/pads
>
> Put attached patch to the new directory and continue as user:
> $ cd source/pads
> $ apt source pads
> $ cd pads-1.2/
> $ patch -p1 < ../pads_print_arp_asset_initialize.patch
> $ dpkg-buildpackage -b
>
> As root (with the directory adjusted to your user):
> # dpkg -i /home/benutzer/source/pads/{pads_1.2-14_amd64.deb,pads-
> dbgsym_1.2-14_amd64.deb}
>
>
> And then see if it still works as expected and see
> if the crash happens again.
>
> Kind regards,
> Bernhard
Bug#1018061: pads: segfault at 3a ip
Hi Benhard,
Okay patch installed, the output is in the attached file.
I was already on 1.2-14 so we'll see if the patch helped or if it was
needed by me.
--
Tim McConnell
On Wed, 2023-03-15 at 12:10 +0100, Bernhard Übelacker wrote:
> Am 26.02.23 um 16:47 schrieb Tim McConnell:
>
> > Hi Bernhard,
> > The delay is fine, I'm sure it takes a minute to figure it out ;-)
> > and
> > no I didn't have anything other than defaults for GDB set. I'm not
> > a
> > programmer so I don't know all the tricks to GDB or when is best
> > to
> > use them. With that said, how would I go about installing /testing
> > the
> > patch you provide? I'm happy to test it out for you, I just need
> > the
> > knowledge of how to.
> > Thanks!
> >
>
>
> Hello Tim,
> if you are fine with installing a bunch of build dependencies
> you could use following steps to rebuild the package with the patch.
>
> As root:
> # apt build-dep pads
>
> As user:
> $ mkdir -p source/pads
>
> Put attached patch to the new directory and continue as user:
> $ cd source/pads
> $ apt source pads
> $ cd pads-1.2/
> $ patch -p1 < ../pads_print_arp_asset_initialize.patch
> $ dpkg-buildpackage -b
>
> As root (with the directory adjusted to your user):
> # dpkg -i /home/benutzer/source/pads/{pads_1.2-14_amd64.deb,pads-
> dbgsym_1.2-14_amd64.deb}
>
>
> And then see if it still works as expected and see
> if the crash happens again.
>
> Kind regards,
> Bernhard
| ^~~~
identification.c:325:26: note: in expansion of macro ‘bdata’
325 | strlcat(app, bdata(sig->title.misc), MAX_MISC);
| ^
util.h:56:39: note: expected ‘const char *’ but argument is of type ‘unsigned
char *’
56 | size_t strlcat(char *dst, const char *src, size_t len);
| ^~~
identification.c: In function ‘parse_raw_signature’:
identification.c:130:14: warning: ‘title’ may be used uninitialized
[-Wmaybe-uninitialized]
130 | if (title->qty < 3)
| ~^
identification.c:94:22: note: ‘title’ was declared here
94 | struct bstrList *title;
| ^
identification.c:170:8: warning: ‘pcre_string’ may be used uninitialized
[-Wmaybe-uninitialized]
170 | if (pcre_string != NULL)
|^
identification.c:96:13: note: ‘pcre_string’ was declared here
96 | bstring pcre_string;
| ^~~
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -Wdate-time -D_FORTIFY_SOURCE=2
-g -O2 -ffile-prefix-map=/home/tmick/source/pads/pads-1.2=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -g -std=gnu89
-c -o packet.o packet.c
In file included from /usr/include/netinet/in.h:21,
from global.h:69,
from packet.h:44,
from packet.c:28:
/usr/include/features.h:194:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE
are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
194 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
_DEFAULT_SOURCE"
| ^~~
packet.c: In function ‘process_arp’:
packet.c:160:46: warning: pointer targets in passing argument 2 of
‘check_arp_asset’ differ in signedness [-Wpointer-sign]
160 | if (check_arp_asset(ip_addr, arph->arp_sha) == 1) {
| ^
| |
| uint8_t * {aka unsigned
char *}
In file included from packet.h:45:
storage.h:58:51: note: expected ‘char *’ but argument is of type ‘uint8_t *’
{aka ‘unsigned char *’}
58 | int check_arp_asset (struct in_addr ip_addr, char mac_addr[MAC_LEN]);
| ~^
packet.c:161:44: warning: pointer targets in passing argument 2 of
‘add_arp_asset’ differ in signedness [-Wpointer-sign]
161 | add_arp_asset(ip_addr, arph->arp_sha, 0);
|^
||
|uint8_t * {aka unsigned char
*}
storage.h:60:50: note: expected ‘char *’ but argument is of type ‘uint8_t *’
{aka ‘unsigned char *’}
60 | void add_arp_asset (struct in_addr ip_addr, char mac_addr[MAC_LEN],
time_t discovered);
| ~^
packet.c:162:47: warning: pointer targets in passing argument 2 of
‘print_arp_asset’ differ in signedness [-Wpointer-sign]
162 | print_arp_asset (ip_addr, arph->arp_sha);
| ^
| |
| uint8_t * {aka unsigned
char *}
In file included from pads.h:52,
from util.h:42,
from mac-resolution.h:40,
Bug#1018061: pads: segfault at 3a ip
Am 26.02.23 um 16:47 schrieb Tim McConnell:
Hi Bernhard,
The delay is fine, I'm sure it takes a minute to figure it out ;-) and
no I didn't have anything other than defaults for GDB set. I'm not a
programmer so I don't know all the tricks to GDB or when is best to
use them. With that said, how would I go about installing /testing the
patch you provide? I'm happy to test it out for you, I just need the
knowledge of how to.
Thanks!
Hello Tim,
if you are fine with installing a bunch of build dependencies
you could use following steps to rebuild the package with the patch.
As root:
# apt build-dep pads
As user:
$ mkdir -p source/pads
Put attached patch to the new directory and continue as user:
$ cd source/pads
$ apt source pads
$ cd pads-1.2/
$ patch -p1 < ../pads_print_arp_asset_initialize.patch
$ dpkg-buildpackage -b
As root (with the directory adjusted to your user):
# dpkg -i
/home/benutzer/source/pads/{pads_1.2-14_amd64.deb,pads-dbgsym_1.2-14_amd64.deb}
And then see if it still works as expected and see
if the crash happens again.
Kind regards,
Bernhard
--- a/src/output/output.c2023-02-26 15:19:32.0 +0100
+++ b/src/output/output.c2023-02-26 15:54:54.007679051 +0100
@@ -182,7 +182,7 @@ int print_arp_asset (struct in_addr ip_a
/* Find Asset */
ArpAsset *list;
-ArpAsset *rec;
+ArpAsset *rec = NULL;
list = (ArpAsset *)get_arp_pointer();
while (list != NULL) {
Bug#1018061: pads: segfault at 3a ip
On Sun, 2023-02-26 at 16:03 +0100, Bernhard Übelacker wrote:
> Am 08.02.23 um 19:31 schrieb Tim McConnell:
> > Opppss I thought I had, here it is.
> > bt full
>
>
> Hello Tim,
> sorry for the delay. For some reason the debug information
> for libpcap.so.0.8 was missing in your backtrace (was the
> DEBUGINFOD_URLS variable set in that console?).
>
> But I guess I could fill in the gaps [2].
>
> And I think in function print_arp_asset the variable rec
> might get used uninitialized.
> This is also warned about in the build log [3].
>
> Therefore the crash could possibly avoided with the patch below [1].
>
> Kind regards,
> Bernhard
>
>
>
> [1]
> --- src/output/output.c.orig 2023-02-26 15:19:32.0 +0100
> +++ src/output/output.c 2023-02-26 15:54:54.007679051 +0100
> @@ -182,7 +182,7 @@ int print_arp_asset (struct in_addr ip_a
>
> /* Find Asset */
> ArpAsset *list;
> - ArpAsset *rec;
> + ArpAsset *rec = NULL;
>
> list = (ArpAsset *)get_arp_pointer();
> while (list != NULL) {
>
>
>
> [2]
> (gdb)
> #0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at
> ./src/output/output-screen.c:115
> #1 0x5641638af6f0 in print_arp_asset (ip_addr=...,
> mac_addr=0x7fa6db692384 "") at ./src/output/output.c:210
> head = 0x5641654a33f0
> list =
> rec = 0x2a
> #2 0x7fa6dbe004f6 in pcap_handle_packet_mmap () at ./pcap-
> linux.c:4072 from /lib/x86_64-linux-gnu/libpcap.so.0.8
> #3 0x7fa6dbe008ec in pcap_read_linux_mmap_v3 () at ./pcap-
> linux.c:4248 from /lib/x86_64-linux-gnu/libpcap.so.0.8
> #4 0x7fa6dbe07d1d in pcap_loop () at ./pcap.c:2923 from
> /lib/x86_64-linux-gnu/libpcap.so.0.8
> #5 0x5641638a8e5b in main_pads () at ./src/pads.c:278
> #6 0x5641638a847b in main (argc=, argv= out>) at ./src/pads.c:491
>
> (gdb) list output.c:210
> 179 int print_arp_asset (struct in_addr ip_addr, char
> mac_addr[MAC_LEN])
> 180 {
> 181 OutputPluginList *head;
> 182
> 183 /* Find Asset */
> 184 ArpAsset *list;
> 185 ArpAsset *rec;
> 186
> 187 list = (ArpAsset *)get_arp_pointer();
> 188 while (list != NULL) {
> 189 if (ip_addr.s_addr == list->ip_addr.s_addr
> 190 && (strcmp(mac_addr, list->mac_addr) == 0)) {
> 191
> 192 /* Found! */
> 193 rec = list;
> 194 break;
> 195 } else {
> 196 list = list->next;
> 197 }
> 198 }
> 199
> 200 /* Make sure that a record was found. */
> 201 if (rec == NULL)
> 202 return 1;
> 203
> 204 /* Cycle through output plugins and print to those that
> are active. */
> 205 head = output_plugin_list;
> 206 while (head != NULL) {
> 207 /* Only print to active plugins. */
> 208 if (head->active == 1) {
> 209 if (head->plugin->print_arp)
> 210 (*head->plugin->print_arp)(rec);
> 211 }
> 212
> 213 head = head->next;
> 214 }
>
>
> [3]
> https://buildd.debian.org/status/fetch.php?pkg=pads=amd64=1.2-14=1665671920=0
> output.c: In function ‘print_arp_asset’:
> output.c:210:18: warning: ‘rec’ may be used uninitialized [-Wmaybe-
> uninitialized]
> 210 | (*head->plugin->print_arp)(rec);
> | ~^~
> output.c:185:15: note: ‘rec’ was declared here
> 185 | ArpAsset *rec;
> | ^~~
>
Hi Bernhard,
The delay is fine, I'm sure it takes a minute to figure it out ;-) and
no I didn't have anything other than defaults for GDB set. I'm not a
programmer so I don't know all the tricks to GDB or when is best to
use them. With that said, how would I go about installing /testing the
patch you provide? I'm happy to test it out for you, I just need the
knowledge of how to.
Thanks!
--
Tim McConnell
Bug#1018061: pads: segfault at 3a ip
Am 08.02.23 um 19:31 schrieb Tim McConnell:
Opppss I thought I had, here it is.
bt full
Hello Tim,
sorry for the delay. For some reason the debug information
for libpcap.so.0.8 was missing in your backtrace (was the
DEBUGINFOD_URLS variable set in that console?).
But I guess I could fill in the gaps [2].
And I think in function print_arp_asset the variable rec
might get used uninitialized.
This is also warned about in the build log [3].
Therefore the crash could possibly avoided with the patch below [1].
Kind regards,
Bernhard
[1]
--- src/output/output.c.orig2023-02-26 15:19:32.0 +0100
+++ src/output/output.c 2023-02-26 15:54:54.007679051 +0100
@@ -182,7 +182,7 @@ int print_arp_asset (struct in_addr ip_a
/* Find Asset */
ArpAsset *list;
-ArpAsset *rec;
+ArpAsset *rec = NULL;
list = (ArpAsset *)get_arp_pointer();
while (list != NULL) {
[2]
(gdb)
#0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at
./src/output/output-screen.c:115
#1 0x5641638af6f0 in print_arp_asset (ip_addr=..., mac_addr=0x7fa6db692384
"") at ./src/output/output.c:210
head = 0x5641654a33f0
list =
rec = 0x2a
#2 0x7fa6dbe004f6 in pcap_handle_packet_mmap () at ./pcap-linux.c:4072
from /lib/x86_64-linux-gnu/libpcap.so.0.8
#3 0x7fa6dbe008ec in pcap_read_linux_mmap_v3 () at ./pcap-linux.c:4248
from /lib/x86_64-linux-gnu/libpcap.so.0.8
#4 0x7fa6dbe07d1d in pcap_loop () at ./pcap.c:2923 from
/lib/x86_64-linux-gnu/libpcap.so.0.8
#5 0x5641638a8e5b in main_pads () at ./src/pads.c:278
#6 0x5641638a847b in main (argc=, argv=) at
./src/pads.c:491
(gdb) list output.c:210
179 int print_arp_asset (struct in_addr ip_addr, char mac_addr[MAC_LEN])
180 {
181 OutputPluginList *head;
182
183 /* Find Asset */
184 ArpAsset *list;
185 ArpAsset *rec;
186
187 list = (ArpAsset *)get_arp_pointer();
188 while (list != NULL) {
189 if (ip_addr.s_addr == list->ip_addr.s_addr
190 && (strcmp(mac_addr, list->mac_addr) == 0)) {
191
192 /* Found! */
193 rec = list;
194 break;
195 } else {
196 list = list->next;
197 }
198 }
199
200 /* Make sure that a record was found. */
201 if (rec == NULL)
202 return 1;
203
204 /* Cycle through output plugins and print to those that are active.
*/
205 head = output_plugin_list;
206 while (head != NULL) {
207 /* Only print to active plugins. */
208 if (head->active == 1) {
209 if (head->plugin->print_arp)
210 (*head->plugin->print_arp)(rec);
211 }
212
213 head = head->next;
214 }
[3]
https://buildd.debian.org/status/fetch.php?pkg=pads=amd64=1.2-14=1665671920=0
output.c: In function ‘print_arp_asset’:
output.c:210:18: warning: ‘rec’ may be used uninitialized
[-Wmaybe-uninitialized]
210 | (*head->plugin->print_arp)(rec);
| ~^~
output.c:185:15: note: ‘rec’ was declared here
185 | ArpAsset *rec;
| ^~~
Bug#1018061: pads: segfault at 3a ip
Opppss I thought I had, here it is. bt full #0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at ./src/output/output-screen.c:115 No locals. #1 0x5641638af6f0 in print_arp_asset (ip_addr=..., mac_addr=0x7fa6db692384 "") at ./src/output/output.c:210 head = 0x5641654a33f0 list = rec = 0x2a #2 0x7fa6dbe004f6 in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #3 0x7fa6dbe008ec in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #4 0x7fa6dbe07d1d in pcap_loop () from /lib/x86_64-linux-gnu/libpcap.so.0.8 No symbol table info available. #5 0x5641638a8e5b in main_pads () at ./src/pads.c:278 No locals. #6 0x5641638a847b in main (argc=, argv=) at ./src/pads.c:491 No locals. (gdb) Quit (gdb) bt full #0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at ./src/output/output-screen.c:115 No locals. #1 0x5641638af6f0 in print_arp_asset (ip_addr=..., mac_addr=0x7fa6db692384 "") at ./src/output/output.c:210 head = 0x5641654a33f0 list = rec = 0x2a #2 0x7fa6dbe004f6 in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #3 0x7fa6dbe008ec in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #4 0x7fa6dbe07d1d in pcap_loop () from /lib/x86_64-linux-gnu/libpcap.so.0.8 No symbol table info available. #5 0x5641638a8e5b in main_pads () at ./src/pads.c:278 No locals. #6 0x5641638a847b in main (argc=, argv=) at ./src/pads.c:491 No locals. (gdb) #0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at ./src/output/output-screen.c:115 No locals. #1 0x5641638af6f0 in print_arp_asset (ip_addr=..., mac_addr=0x7fa6db692384 "") at ./src/output/output.c:210 head = 0x5641654a33f0 list = rec = 0x2a #2 0x7fa6dbe004f6 in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #3 0x7fa6dbe008ec in ?? () from /lib/x86_64-linux- gnu/libpcap.so.0.8 No symbol table info available. #4 0x7fa6dbe07d1d in pcap_loop () from /lib/x86_64-linux-gnu/libpcap.so.0.8 No symbol table info available. #5 0x5641638a8e5b in main_pads () at ./src/pads.c:278 No locals. #6 0x5641638a847b in main (argc=, argv=) at ./src/pads.c:491 No locals. (gdb) -- Tim McConnell On Wed, 2023-02-08 at 19:26 +0100, Bernhard Übelacker wrote: > Am 08.02.23 um 18:42 schrieb Tim McConnell: > > Hi Bernhard, > > Okay I did that. Let me know if that was of any use. > > Hello Tim, > could you send the actual output below the `bt full`? > > Kind regards, > Bernhard
Bug#1018061: pads: segfault at 3a ip
Am 08.02.23 um 18:42 schrieb Tim McConnell: Hi Bernhard, Okay I did that. Let me know if that was of any use. Hello Tim, could you send the actual output below the `bt full`? Kind regards, Bernhard
Bug#1018061: pads: segfault at 3a ip
Hi Bernhard, Okay I did that. Let me know if that was of any use. -- Tim McConnell On Wed, 2023-02-08 at 16:16 +0100, Bernhard Übelacker wrote: > bt full
Bug#1018061: pads: segfault at 3a ip
Hello Tim, thanks, that is good helpful information, but as long the core file might be in the system, could you execute following commands: export DEBUGINFOD_URLS="https://debuginfod.debian.net; coredumpctl gdb 1546 (gdb) bt full This will enable gdb to download needed debug symbol files, and the `bt` command to gdb can then show a backtrace with source line information (hopefully). The debug symbols get downloaded to "/root/.cache/debuginfod_client". Kind regards, Bernhard Am 07.02.23 um 20:25 schrieb Tim McConnell: New Backtrace: Stack trace of thread 1546: #0 0x5641638af954 print_arp_asset_screen (pads + 0x9954) #1 0x5641638af6f0 print_arp_asset (pads + 0x96f0) #2 0x7fa6dbe004f6 n/a (libpcap.so.0.8 + 0x84f6) #3 0x7fa6dbe008ec n/a (libpcap.so.0.8 + 0x88ec) #4 0x7fa6dbe07d1d pcap_loop (libpcap.so.0.8 + 0xfd1d) #5 0x5641638a8e5b main_pads (pads + 0x2e5b) #6 0x5641638a847b main (pads + 0x247b)
Bug#1018061: pads: segfault at 3a ip
New Backtrace:
coredumpctl gdb -1
PID: 1546 (pads)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Tue 2023-02-07 10:08:03 CST (3h 14min ago)
Command Line: /usr/bin/pads -D -c /etc/pads/pads.conf
Executable: /usr/bin/pads
Control Group: /system.slice/pads.service
Unit: pads.service
Slice: system.slice
Boot ID: 90f7db29bc44436f8b4d1a2cbfc52a5c
Machine ID: dacda8ffae4a44148edc6518f73d4b00
Hostname: DebianTim
Storage:
/var/lib/systemd/coredump/core.pads.0.90f7db29bc44436f8b4d1a2cbfc52a5c.
1546.167578608300.zst (present)
Size on Disk: 329.8K
Message: Process 1546 (pads) of user 0 dumped core.
Module libsystemd.so.0 from deb systemd-252.5-2.amd64
Stack trace of thread 1546:
#0 0x5641638af954 print_arp_asset_screen (pads +
0x9954)
#1 0x5641638af6f0 print_arp_asset (pads + 0x96f0)
#2 0x7fa6dbe004f6 n/a (libpcap.so.0.8 + 0x84f6)
#3 0x7fa6dbe008ec n/a (libpcap.so.0.8 + 0x88ec)
#4 0x7fa6dbe07d1d pcap_loop (libpcap.so.0.8 +
0xfd1d)
#5 0x5641638a8e5b main_pads (pads + 0x2e5b)
#6 0x5641638a847b main (pads + 0x247b)
#7 0x7fa6dbc3718a __libc_start_call_main
(libc.so.6 + 0x2718a)
#8 0x7fa6dbc37245 __libc_start_main_impl
(libc.so.6 + 0x27245)
#9 0x5641638a84b1 _start (pads + 0x24b1)
ELF object binary architecture: AMD x86-64
--
Tim McConnell
On Tue, 2022-09-27 at 10:32 +0200, Bernhard Übelacker wrote:
> Hello Tim,
> I tried to have a look at those two dmesg lines and it seems
> they point to the function print_arp_asset_screen, line 115 [1],
> where parameter rec is dereferenced unconditionally.
>
> However, if it would be possible to install systemd-coredump then
> a backtrace of those crashes should be printed to the journal.
> This would give a way better information as the two dmesg lines
> alone,
> as it would also show the functions calling print_arp_asset_screen
> and therefore leading to the crash.
>
> The link [2] might give some more hints to collect
> more information for the maintainer.
>
> Kind regards,
> Bernhard
>
>
> [1]
> https://sources.debian.org/src/pads/1.2-13/src/output/output-screen.c/#L115
> 112 print_arp_asset_screen (ArpAsset *rec)
> 113 {
> 114 /* Print to Screen */
> 115 if(rec->mac_resolved != NULL) {
> 116fprintf(stdout, "[*] Asset Found: IP Address - %s /
> MAC Address - %s (%s)\n",
>
> [2] https://wiki.debian.org/HowToGetABacktrace
Bug#1018061: pads: segfault at 3a ip
Hi Bernhard,
I guess there was an upgrade that resolved the issue. I no longer see
any errors for PADS. I guess it could be called an "undocumented
feature" of the upgrade?
Anyway this can be closed as resolved.
Thanks!
--
Tim McConnell
On Tue, 2022-09-27 at 10:32 +0200, Bernhard Übelacker wrote:
> Hello Tim,
> I tried to have a look at those two dmesg lines and it seems
> they point to the function print_arp_asset_screen, line 115 [1],
> where parameter rec is dereferenced unconditionally.
>
> However, if it would be possible to install systemd-coredump then
> a backtrace of those crashes should be printed to the journal.
> This would give a way better information as the two dmesg lines
> alone,
> as it would also show the functions calling print_arp_asset_screen
> and therefore leading to the crash.
>
> The link [2] might give some more hints to collect
> more information for the maintainer.
>
> Kind regards,
> Bernhard
>
>
> [1]
> https://sources.debian.org/src/pads/1.2-13/src/output/output-screen.c/#L115
> 112 print_arp_asset_screen (ArpAsset *rec)
> 113 {
> 114 /* Print to Screen */
> 115 if(rec->mac_resolved != NULL) {
> 116fprintf(stdout, "[*] Asset Found: IP Address - %s /
> MAC Address - %s (%s)\n",
>
> [2] https://wiki.debian.org/HowToGetABacktrace
Bug#1018061: pads: segfault at 3a ip
Hi Bernhard, Installed and read the link. I'll see if I can get more useful information for the maintainer. Thanks for the suggestions on how to get it. -- Tim McConnell On Tue, 2022-09-27 at 10:32 +0200, Bernhard Übelacker wrote: > if it would be possible to install systemd-coredump then > a backtrace of those crashes should be printed to the journal.
Bug#1018061: pads: segfault at 3a ip
Hello Tim,
I tried to have a look at those two dmesg lines and it seems
they point to the function print_arp_asset_screen, line 115 [1],
where parameter rec is dereferenced unconditionally.
However, if it would be possible to install systemd-coredump then
a backtrace of those crashes should be printed to the journal.
This would give a way better information as the two dmesg lines alone,
as it would also show the functions calling print_arp_asset_screen
and therefore leading to the crash.
The link [2] might give some more hints to collect
more information for the maintainer.
Kind regards,
Bernhard
[1] https://sources.debian.org/src/pads/1.2-13/src/output/output-screen.c/#L115
112 print_arp_asset_screen (ArpAsset *rec)
113 {
114 /* Print to Screen */
115 if(rec->mac_resolved != NULL) {
116 fprintf(stdout, "[*] Asset Found: IP Address - %s / MAC Address -
%s (%s)\n",
[2] https://wiki.debian.org/HowToGetABacktrace
# 2022-09-27 Bookworm/testing qemu amd64 VM
apt install systemd-coredump mc gdb pads pads-dbgsym
apt build-dep pads
mkdir /home/benutzer/source/pads/orig -p
cd/home/benutzer/source/pads/orig
apt source pads
cd
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
[87486.873713] pads[2092050]: segfault at 3a ip 5569c2dadb64 sp
7ffc6ce82ed0 error 4 in pads[5569c2da6000+9000]
[87486.873733] Code: 23 00 00 be 01 00 00 00 0f b7 c9 e8 46 85 ff ff 58 31 c0
5a 5b 5d 41 5c c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 41 54 55 53 <48> 8b 47
10 48 89 fb 48 83 c7 04 48 85 c0 74 44 4c 8b 60 08 e8 b3
error 4 == 0b0100
* bit 0 ==0: no page found
* bit 1 ==0: read access
* bit 2 ==1: user-mode access
echo -n "find /b ..., ..., 0x" && \
echo "23 00 00 be 01 00 00 00 0f b7 c9 e8 46 85 ff ff 58 31 c0 5a 5b 5d 41 5c
c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 41 54 55 53 <48> 8b 47 10 48 89 fb 48
83 c7 04 48 85 c0 74 44 4c 8b 60 08 e8 b3" \
| sed 's/[<>]//g' | sed 's/ /, 0x/g'
benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/pads
Reading symbols from /usr/bin/pads...
Reading symbols from
/usr/lib/debug/.build-id/56/25dea5149cbe3b93f99e31e95d4e8920ce5a73.debug...
(gdb) b main
Breakpoint 1 at 0x2470: file ./src/pads.c, line 486.
(gdb) run
Starting program: /usr/bin/pads
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=1, argv=0x7fffe5a8) at ./src/pads.c:486
486 ./src/pads.c: Datei oder Verzeichnis nicht gefunden.
(gdb) directory /home/benutzer/source/pads/orig/pads-1.2
Source directories searched: /home/benutzer/source/pads/orig/pads-1.2:$cdir:$cwd
(gdb) dele 1
(gdb) pipe info target | grep ".text"
0x6460 - 0xe8a1 is .text
0x77fcc050 - 0x77ff0391 is .text in
/lib64/ld-linux-x86-64.so.2
0x77fc96c0 - 0x77fc9d1d is .text in system-supplied DSO
at 0x77fc9000
0x77f4b1e0 - 0x77f9f322 is .text in
/lib/x86_64-linux-gnu/libpcre.so.3
0x77f038b0 - 0x77f29c4e is .text in
/lib/x86_64-linux-gnu/libpcap.so.0.8
0x77c28380 - 0x77d94e9d is .text in
/lib/x86_64-linux-gnu/libc.so.6
0x77ef9040 - 0x77ef9101 is .text in
/lib/x86_64-linux-gnu/libpthread.so.0
0x77eb0e30 - 0x77edf098 is .text in
/lib/x86_64-linux-gnu/libdbus-1.so.3
0x77b46af0 - 0x77bc241c is .text in
/lib/x86_64-linux-gnu/libsystemd.so.0
0x77e973d0 - 0x77e9a4b6 is .text in
/lib/x86_64-linux-gnu/libcap.so.2
0x779f7580 - 0x77ae0128 is .text in
/lib/x86_64-linux-gnu/libgcrypt.so.20
0x77e6f510 - 0x77e865b2 is .text in
/lib/x86_64-linux-gnu/liblzma.so.5
0x77934740 - 0x779d0636 is .text in
/lib/x86_64-linux-gnu/libzstd.so.1
0x77e493e0 - 0x77e66437 is .text in
/lib/x86_64-linux-gnu/liblz4.so.1
0x77e206c0 - 0x77e3600e is .text in
/lib/x86_64-linux-gnu/libgpg-error.so.0
(gdb) find /b 0x6460, 0xe8a1, 0x23, 0x00, 0x00, 0xbe,
0x01, 0x00, 0x00, 0x00, 0x0f, 0xb7, 0xc9, 0xe8, 0x46, 0x85, 0xff, 0xff, 0x58,
0x31, 0xc0, 0x5a, 0x5b, 0x5d, 0x41, 0x5c, 0xc3, 0x66, 0x66, 0x2e, 0x0f, 0x1f,
0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x66, 0x90, 0x41, 0x54, 0x55, 0x53, 0x48,
0x8b, 0x47, 0x10, 0x48, 0x89, 0xfb, 0x48, 0x83, 0xc7, 0x04, 0x48, 0x85, 0xc0,
0x74, 0x44, 0x4c, 0x8b, 0x60, 0x08, 0xe8, 0xb3
0xdb3a
1 pattern found.
(gdb) b * (0xdb3a + 42)
Breakpoint 2 at 0xdb64: file ./src/output/output-screen.c, line 115.
(gdb) info b
Num Type Disp Enb AddressWhat
2 breakpoint keep y 0xdb64 in print_arp_asset_screen at
./src/output/output-screen.c:115
(gdb) disassemble /r 0xf7a94b31,
Bug#1018061: pads: segfault at 3a ip
Package: pads Version: 1.2-13 Severity: important Dear Maintainer, In dmesg I noticed this: [87486.873713] pads[2092050]: segfault at 3a ip 5569c2dadb64 sp 7ffc6ce82ed0 error 4 in pads[5569c2da6000+9000] [87486.873733] Code: 23 00 00 be 01 00 00 00 0f b7 c9 e8 46 85 ff ff 58 31 c0 5a 5b 5d 41 5c c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 41 54 55 53 <48> 8b 47 10 48 89 fb 48 83 c7 04 48 85 c0 74 44 4c 8b 60 08 e8 b3 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pads depends on: ii init-system-helpers 1.64 ii libc62.34-4 ii libpcap0.8 1.10.1-4 ii libpcre3 2:8.39-14 ii lsb-base 11.2 pads recommends no packages. pads suggests no packages. -- no debconf information
