Re: slaacd: backwards memcpy

[Theo de Raadt]

Theo de Raadt  wrote:

> Sebastien Marie  wrote:
> 
> > On Sat, Dec 07, 2019 at 11:47:58AM +0100, Sebastien Marie wrote:
> > > 
> > > For now, I recompiled slaacd with debug symbols, and will keep it running 
> > > like
> > > that in order to catch it the next time. But such switchs aren't very
> > > frequent...
> > 
> > A new one, with symbols this time. I still saw it only i386 and aarch64 (not
> > on amd64).
> > 
> > $ sysctl kern.version
> > kern.version=OpenBSD 6.6-current (GENERIC.MP) #103: Wed Dec  4 20:10:51 CET 
> > 2019
> > semarie@bert.local:/home/openbsd/src/sys/arch/i386/compile/GENERIC.MP
> > 
> > $ doas egdb /sbin/slaacd /slaacd.core
> > GNU gdb (GDB) 7.12.1
> > Copyright (C) 2017 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later 
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "i386-unknown-openbsd6.5".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /sbin/slaacd...done.
> > [New process 221665]
> > 
> > warning: Unexpected size of section `.reg2/221665' in core file.
> > Core was generated by `slaacd'.
> > Program terminated with signal SIGABRT, Aborted.
> > 
> > warning: Unexpected size of section `.reg2/221665' in core file.
> > #0  thrkill () at -:3
> > 3   -: No such file or directory.
> > (gdb) bt
> > #0  thrkill () at -:3
> > #1  0x15dcde20 in _libc_raise (s=6) at 
> > /home/openbsd/src/lib/libc/gen/raise.c:37
> > #2  0x15dcddab in _libc_abort () at 
> > /home/openbsd/src/lib/libc/stdlib/abort.c:51
> > #3  0x15dcdd60 in memcpy (dst0=0xcf7f4c88, src0=0xcf7f4c3c, length=272) at 
> > /home/openbsd/src/lib/libc/string/memcpy.c:74
> > #4  0x15d8f1a2 in delete_address (address=) at 
> > /home/openbsd/src/sbin/slaacd/slaacd.c:730
> > #5  main_dispatch_engine (fd=, event=2, bula=0x761bd000) at 
> > /home/openbsd/src/sbin/slaacd/slaacd.c:534
> > #6  0x15d91058 in event_process_active (base=) at 
> > /home/openbsd/src/lib/libevent/event.c:333
> > #7  event_base_loop (base=0x49a33c00, flags=0) at 
> > /home/openbsd/src/lib/libevent/event.c:483
> > #8  0x15d90af1 in event_loop (flags= > memory at address 0x0>) at /home/openbsd/src/lib/libevent/event.c:409
> > #9  event_dispatch () at /home/openbsd/src/lib/libevent/event.c:347
> > #10 0x15d8e92e in main (argc=, argv=0xcf7f5064) at 
> > /home/openbsd/src/sbin/slaacd/slaacd.c:305
> > 
> > From frame #3, it means:
> > 
> > memcpy(_ridreq.ifr_ifru, >addr, 
> > sizeof(in6_ridreq.ifr_ifru));
> > 
> > _ridreq.ifr_ifru is at 0xcf7f4c88
> > >addr   is at 0xcf7f4c3c
> > sizeof(in6_ridreq.ifr_ifru) is 272
> > 
> > `address' is from the stack in frame #5 (main_dispatch_engine), and 
> > `in6_ridreq' is
> > from the stack in frame #4 (delete_address).
> > 
> > `address->addr' is a `struct sockaddr_in6' and the sizeof() is 26 bytes.
> > `in6_ridreq.ifr_ifru' is a union with `struct  sockaddr_in6' in member, but 
> > the
> > total sizeof() is 272 (I assume due to bigger members).
> > 
> > so memcpy() will read 272 bytes from the stack, even if the source is only 
> > 26
> > bytes long. some bytes will come from outside the variable, specially from 
> > the
> > next variable on the stack, and in this case it is from `in6_ridreq' itself,
> > resulting in backwards memcpy.
> 
> It should use the specific element in the union, so this might be the
> fix.
> 
> Index: slaacd.c
> ===
> RCS file: /cvs/src/sbin/slaacd/slaacd.c,v
> retrieving revision 1.45
> diff -u -p -u -r1.45 slaacd.c
> --- slaacd.c  23 Nov 2019 08:17:39 -  1.45
> +++ slaacd.c  15 Dec 2019 06:31:02 -
> @@ -727,8 +727,8 @@ delete_address(struct imsg_configure_add
>   return;
>   }
>  
> - memcpy(_ridreq.ifr_ifru, >addr,
> - sizeof(in6_ridreq.ifr_ifru));
> + memcpy(_ridreq.ifr_ifru.ifru_addr, >addr,
> + sizeof(in6_ridreq.ifr_ifru.ifru_addr));
>  
>   log_debug("%s: %s", __func__, if_name);

Or even better, via the typical macro expansion used for this type of
union, it should use ifr_addr

Index: slaacd.c
===
RCS file: /cvs/src/sbin/slaacd/slaacd.c,v
retrieving revision 1.45
diff -u -p -u -r1.45 slaacd.c
--- slaacd.c23 Nov 2019 08:17:39 -  1.45
+++ slaacd.c15 Dec 2019 07:00:47 -
@@ -727,8 +727,8 @@ delete_address(struct imsg_configure_add
return;
}
 
-  

Re: slaacd: backwards memcpy

[Theo de Raadt]

Sebastien Marie  wrote:

> On Sat, Dec 07, 2019 at 11:47:58AM +0100, Sebastien Marie wrote:
> > 
> > For now, I recompiled slaacd with debug symbols, and will keep it running 
> > like
> > that in order to catch it the next time. But such switchs aren't very
> > frequent...
> 
> A new one, with symbols this time. I still saw it only i386 and aarch64 (not
> on amd64).
> 
> $ sysctl kern.version
> kern.version=OpenBSD 6.6-current (GENERIC.MP) #103: Wed Dec  4 20:10:51 CET 
> 2019
> semarie@bert.local:/home/openbsd/src/sys/arch/i386/compile/GENERIC.MP
> 
> $ doas egdb /sbin/slaacd /slaacd.core
> GNU gdb (GDB) 7.12.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i386-unknown-openbsd6.5".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /sbin/slaacd...done.
> [New process 221665]
> 
> warning: Unexpected size of section `.reg2/221665' in core file.
> Core was generated by `slaacd'.
> Program terminated with signal SIGABRT, Aborted.
> 
> warning: Unexpected size of section `.reg2/221665' in core file.
> #0  thrkill () at -:3
> 3   -: No such file or directory.
> (gdb) bt
> #0  thrkill () at -:3
> #1  0x15dcde20 in _libc_raise (s=6) at 
> /home/openbsd/src/lib/libc/gen/raise.c:37
> #2  0x15dcddab in _libc_abort () at 
> /home/openbsd/src/lib/libc/stdlib/abort.c:51
> #3  0x15dcdd60 in memcpy (dst0=0xcf7f4c88, src0=0xcf7f4c3c, length=272) at 
> /home/openbsd/src/lib/libc/string/memcpy.c:74
> #4  0x15d8f1a2 in delete_address (address=) at 
> /home/openbsd/src/sbin/slaacd/slaacd.c:730
> #5  main_dispatch_engine (fd=, event=2, bula=0x761bd000) at 
> /home/openbsd/src/sbin/slaacd/slaacd.c:534
> #6  0x15d91058 in event_process_active (base=) at 
> /home/openbsd/src/lib/libevent/event.c:333
> #7  event_base_loop (base=0x49a33c00, flags=0) at 
> /home/openbsd/src/lib/libevent/event.c:483
> #8  0x15d90af1 in event_loop (flags= memory at address 0x0>) at /home/openbsd/src/lib/libevent/event.c:409
> #9  event_dispatch () at /home/openbsd/src/lib/libevent/event.c:347
> #10 0x15d8e92e in main (argc=, argv=0xcf7f5064) at 
> /home/openbsd/src/sbin/slaacd/slaacd.c:305
> 
> From frame #3, it means:
> 
>   memcpy(_ridreq.ifr_ifru, >addr, 
> sizeof(in6_ridreq.ifr_ifru));
> 
>   _ridreq.ifr_ifru is at 0xcf7f4c88
>   >addr   is at 0xcf7f4c3c
>   sizeof(in6_ridreq.ifr_ifru) is 272
> 
> `address' is from the stack in frame #5 (main_dispatch_engine), and 
> `in6_ridreq' is
> from the stack in frame #4 (delete_address).
> 
> `address->addr' is a `struct sockaddr_in6' and the sizeof() is 26 bytes.
> `in6_ridreq.ifr_ifru' is a union with `struct  sockaddr_in6' in member, but 
> the
> total sizeof() is 272 (I assume due to bigger members).
> 
> so memcpy() will read 272 bytes from the stack, even if the source is only 26
> bytes long. some bytes will come from outside the variable, specially from the
> next variable on the stack, and in this case it is from `in6_ridreq' itself,
> resulting in backwards memcpy.

It should use the specific element in the union, so this might be the
fix.

Index: slaacd.c
===
RCS file: /cvs/src/sbin/slaacd/slaacd.c,v
retrieving revision 1.45
diff -u -p -u -r1.45 slaacd.c
--- slaacd.c23 Nov 2019 08:17:39 -  1.45
+++ slaacd.c15 Dec 2019 06:31:02 -
@@ -727,8 +727,8 @@ delete_address(struct imsg_configure_add
return;
}
 
-   memcpy(_ridreq.ifr_ifru, >addr,
-   sizeof(in6_ridreq.ifr_ifru));
+   memcpy(_ridreq.ifr_ifru.ifru_addr, >addr,
+   sizeof(in6_ridreq.ifr_ifru.ifru_addr));
 
log_debug("%s: %s", __func__, if_name);
 

Re: slaacd: backwards memcpy

[Sebastien Marie]

On Sat, Dec 07, 2019 at 11:47:58AM +0100, Sebastien Marie wrote:
> 
> For now, I recompiled slaacd with debug symbols, and will keep it running like
> that in order to catch it the next time. But such switchs aren't very
> frequent...

A new one, with symbols this time. I still saw it only i386 and aarch64 (not
on amd64).

$ sysctl kern.version
kern.version=OpenBSD 6.6-current (GENERIC.MP) #103: Wed Dec  4 20:10:51 CET 2019
semarie@bert.local:/home/openbsd/src/sys/arch/i386/compile/GENERIC.MP

$ doas egdb /sbin/slaacd /slaacd.core
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd6.5".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /sbin/slaacd...done.
[New process 221665]

warning: Unexpected size of section `.reg2/221665' in core file.
Core was generated by `slaacd'.
Program terminated with signal SIGABRT, Aborted.

warning: Unexpected size of section `.reg2/221665' in core file.
#0  thrkill () at -:3
3   -: No such file or directory.
(gdb) bt
#0  thrkill () at -:3
#1  0x15dcde20 in _libc_raise (s=6) at /home/openbsd/src/lib/libc/gen/raise.c:37
#2  0x15dcddab in _libc_abort () at /home/openbsd/src/lib/libc/stdlib/abort.c:51
#3  0x15dcdd60 in memcpy (dst0=0xcf7f4c88, src0=0xcf7f4c3c, length=272) at 
/home/openbsd/src/lib/libc/string/memcpy.c:74
#4  0x15d8f1a2 in delete_address (address=) at 
/home/openbsd/src/sbin/slaacd/slaacd.c:730
#5  main_dispatch_engine (fd=, event=2, bula=0x761bd000) at 
/home/openbsd/src/sbin/slaacd/slaacd.c:534
#6  0x15d91058 in event_process_active (base=) at 
/home/openbsd/src/lib/libevent/event.c:333
#7  event_base_loop (base=0x49a33c00, flags=0) at 
/home/openbsd/src/lib/libevent/event.c:483
#8  0x15d90af1 in event_loop (flags=) at /home/openbsd/src/lib/libevent/event.c:409
#9  event_dispatch () at /home/openbsd/src/lib/libevent/event.c:347
#10 0x15d8e92e in main (argc=, argv=0xcf7f5064) at 
/home/openbsd/src/sbin/slaacd/slaacd.c:305

>From frame #3, it means:

memcpy(_ridreq.ifr_ifru, >addr, 
sizeof(in6_ridreq.ifr_ifru));

_ridreq.ifr_ifru is at 0xcf7f4c88
>addr   is at 0xcf7f4c3c
sizeof(in6_ridreq.ifr_ifru) is 272

`address' is from the stack in frame #5 (main_dispatch_engine), and 
`in6_ridreq' is
from the stack in frame #4 (delete_address).

`address->addr' is a `struct sockaddr_in6' and the sizeof() is 26 bytes.
`in6_ridreq.ifr_ifru' is a union with `struct  sockaddr_in6' in member, but the
total sizeof() is 272 (I assume due to bigger members).

so memcpy() will read 272 bytes from the stack, even if the source is only 26
bytes long. some bytes will come from outside the variable, specially from the
next variable on the stack, and in this case it is from `in6_ridreq' itself,
resulting in backwards memcpy.

Thanks.
-- 
Sebastien Marie

Re: Memory leak in rip engine (ripd)

[Remi Locherer]

On Mon, Dec 09, 2019 at 03:16:20PM +1100, Jason Tubnor wrote:
> On Mon, 9 Dec 2019 at 10:44, Remi Locherer  wrote:
> 
> >
> > >
> > > I can reproduce this issue. But only when I combine the use of
> > > "interface XY { passive }" and "redistribute connected". When I remove
> > > the passive interfaces from ripd.conf memory consumption is stable.
> > >
> > > Why do you combine these configs?
> >
> > Below diff fixes the memory leak for me.
> >
> > In addition to clear r_list I also moved the check for passive interface
> > a bit up so that the function can return as soon as possible.
> >
> > OK?
> >
> > Remi
> >
> >
> >
> >
> This patch applied cleanly and has fixed the memory leak issue when
> interfaces are configured 'passive'.  Tested with 1 active and 6 passive
> interfaces on one host and with a little memory consumption on startup
> [expected], it settled back down to 984KB of consumed RAM for 391 subnets
> and didn't move over 1.5 hours.
> 
> As /cvs/src/usr.sbin/ripd/message.c hasn't been touched since 2014, this
> patch would apply cleanly to 6.5 and 6.6 if an errata notice needed to be
> created (I can test on these if validation is required - will just take a
> little time to spin them up).
> 
> Thanks for your help Remi.
> 
> Cheers,
> 
> Jason.

Any OKs for this?

Below again the patch.

Remi




Index: message.c
===
RCS file: /cvs/src/usr.sbin/ripd/message.c,v
retrieving revision 1.12
diff -u -p -r1.12 message.c
--- message.c   25 Oct 2014 03:23:49 -  1.12
+++ message.c   8 Dec 2019 23:35:42 -
@@ -105,15 +105,15 @@ send_triggered_update(struct iface *ifac
u_int16_tafi, route_tag;
u_int32_taddress, netmask, nexthop, metric;
 
+   if (iface->passive)
+   return (0);
+
inet_aton(ALL_RIP_ROUTERS, _addr);
 
dst.sin_port = htons(RIP_PORT);
dst.sin_family = AF_INET;
dst.sin_len = sizeof(struct sockaddr_in);
 
-   if (iface->passive)
-   return (0);
-
if ((buf = ibuf_open(iface->mtu - sizeof(struct ip) -
sizeof(struct udphdr))) == NULL)
fatal("send_triggered_update");
@@ -166,13 +166,15 @@ send_request(struct packet_head *r_list,
port = htons(RIP_PORT);
}
 
+   if (iface->passive) {
+   clear_list(r_list);
+   return (0);
+   }
+
dst.sin_port = port;
dst.sin_family = AF_INET;
dst.sin_len = sizeof(struct sockaddr_in);
 
-   if (iface->passive)
-   return (0);
-
while (!TAILQ_EMPTY(r_list)) {
if ((buf = ibuf_open(iface->mtu - sizeof(struct ip) -
sizeof(struct udphdr))) == NULL)
@@ -240,13 +242,15 @@ send_response(struct packet_head *r_list
port = htons(RIP_PORT);
}
 
+   if (iface->passive) {
+   clear_list(r_list);
+   return (0);
+   }
+
dst.sin_port = port;
dst.sin_family = AF_INET;
dst.sin_len = sizeof(struct sockaddr_in);
 
-   if (iface->passive)
-   return (0);
-
while (!TAILQ_EMPTY(r_list)) {
if ((buf = ibuf_open(iface->mtu - sizeof(struct ip) -
sizeof(struct udphdr))) == NULL)

Unreproducible ext2-related crash

[Dumitru Moldovan]

Hi,

OpenBSD 6.6 stable here, with up-to-date binary patches.

Crashed happened while rsync'ing over the wireless interface some large
MPEG2 files to an EXT3 partitition mounted from a secondary HDD.  This
took a few days, but there was only one crash.

Screen shots uploaded to https://imgur.com/a/ZG8u8T7.  Other info below,
as per openbsd.org/report.html and openbsd.org/ddb.html.

Thanks!


$ mount
/dev/sd2a on / type ffs (local)
/dev/sd2e on /home type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd2d on /usr/local type ffs (local, noatime, nodev, wxallowed, softdep)
mfs:65720 on /tmp type mfs (asynchronous, local, size=2048 1M-blocks)
mfs:68790 on /var/cache type mfs (asynchronous, local, size=128 1M-blocks)
mfs:15323 on /var/run type mfs (asynchronous, local, size=16 1M-blocks)
mfs:1095 on /home/dumol/.cache type mfs (asynchronous, local, size=1024 
1M-blocks)
/dev/sd1l on /home/dumol/mnt type ext2fs (local)


This is what fsck found after a reboot:

$ doas fsck.ext3 /dev/sd1l
e2fsck 1.42.12 (29-Aug-2014)
/dev/sd1l contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 49096, i_blocks is 544, should be 104.  Fix? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -76218375 -(78282756--78282759) 
-(78315524--78315527) -(78348292--78348295) -(78381060--78381063) 
-(78413828--78413831) -(78446596--78446599) -(78479364--78479367) 
-(78512132--78512135) -(78544900--78544903) -(78577668--78577671) 
-(78610436--78610439) -(78643204--78643207) -(79152076--79154189)
Fix? yes
Free blocks count wrong for group #2326 (0, counted=1).
Fix? yes
Free blocks count wrong for group #2389 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2390 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2391 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2392 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2393 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2394 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2395 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2396 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2397 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2398 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2399 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2400 (0, counted=4).
Fix? yes
Free blocks count wrong for group #2415 (2114, counted=2120).
Fix? yes
Free blocks count wrong (222521886, counted=222521941).
Fix? yes

/dev/sd1l: * FILE SYSTEM WAS MODIFIED *
/dev/sd1l: 35405/344928 files (30.0% non-contiguous), 130655249/353177190 blocks



DMESG output:

OpenBSD 6.6 (GENERIC.MP) #3: Thu Nov 21 03:20:01 MST 2019
   r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8572698624 (8175MB)
avail mem = 8300171264 (7915MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f000 (68 entries)
bios0: vendor American Megatrends Inc. version "0505" date 11/17/2009
bios0: ASUSTeK Computer INC. M4A785TD-V EVO
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) 
PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) P0PC(S4) UHC1(S4) UHC2(S4) 
UHC3(S4) USB4(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II X2 240e Processor, 2812.74 MHz, 10-06-02
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) II X2 240e Processor, 2812.36 MHz, 10-06-02
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries 

Re: radiusd(8) bsdauth crashes if user authenticates with a mechanism ":style" and group checking on

[Todd C . Miller]

On Fri, 13 Dec 2019 22:37:31 +0200, Dennis Lindroos wrote:

> If the user argument has the ":style" suffix attached to it then
> getpwnam(user) will return a NULL pointer.
> I tried just using strsep(3) to strip off the auth style and it works for
> me (this is probably not the safest bit of coding but i'm sure you figure
> out).

I think this is a safer approach.

 - todd

Index: usr.sbin/radiusd/radiusd_bsdauth.c
===
RCS file: /cvs/src/usr.sbin/radiusd/radiusd_bsdauth.c,v
retrieving revision 1.13
diff -u -p -u -r1.13 radiusd_bsdauth.c
--- usr.sbin/radiusd/radiusd_bsdauth.c  3 Dec 2019 17:45:02 -   1.13
+++ usr.sbin/radiusd/radiusd_bsdauth.c  14 Dec 2019 15:14:29 -
@@ -189,6 +189,7 @@ main(int argc, char *argv[])
group = user + args->userlen;
group[args->grouplen - 1] = '\0';
 
+   user[strcspn(user, ":")] = '\0';
pw = getpwnam(user);
if (pw == NULL)
goto invalid;