Re: ssh needs sendfd in pledge call?
Hi,
As Timothy reported, and with the options he selected for ssh then the codepath
taken will call mux_client_request_session -> mm_send_fd -> sendmsg(2). Since
sendmsg(2) is not allowed in that codepath then pledge(2) kills the process.
Please see below the trace he provided privately, and also his diff beneath it
which adds "sendfd" to pledge(2). In my opinion it's not that bad to add yet
another promise since a little bit later we'll reduce it into "stdio proc tty".
Comments? OK?
[New process 396642]
Core was generated by `ssh'.
Program terminated with signal SIGABRT, Aborted.
#0 _thread_sys_sendmsg () at -:3
#0 _thread_sys_sendmsg () at -:3
No locals.
#1 0x072d95537d7e in _libc_sendmsg_cancel (s=4, msg=0x7f7f26b0,
flags=0) at /usr/src/lib/libc/sys/w_sendmsg.c:27
_tib = 0x72d25280d80
#2 0x072afb52cb22 in mm_send_fd (sock=4, fd=0) at
/usr/src/usr.bin/ssh/ssh/../monitor_fdpass.c:70
cmsg = 0x0014
msg = {
msg_name = 0x0,
msg_namelen = 0,
msg_iov = 0x7f7f26e8,
msg_iovlen = 1,
msg_control = 0x7f7f26f8,
msg_controllen = 24,
msg_flags = 0
}
pfd = {
fd = 4,
events = 4,
revents = 0
}
n =
#3 0x072afb4e4183 in mux_client_request_session (fd=) at
/usr/src/usr.bin/ssh/ssh/../mux.c:1944
devnull =
term =
echar =
m =
r =
i =
type =
rid =
sid =
rawmode =
exitval =
exitval_seen =
esid =
e =
#4 muxclient (path=) at /usr/src/usr.bin/ssh/ssh/../mux.c:2359
sock =
pid =
#5 0x072afb4d14a8 in control_persist_detach () at
/usr/src/usr.bin/ssh/ssh/../ssh.c:1538
pid =
devnull =
#6 fork_postauth () at /usr/src/usr.bin/ssh/ssh/../ssh.c:1563
No locals.
#7 0x072afb4d1630 in ssh_confirm_remote_forward (ssh=0x72d84623780,
type=, seq=, ctxt=0x72d4049d540)
at /usr/src/usr.bin/ssh/ssh/../ssh.c:1632
rfwd = 0x72d4049d540
port =
r =
#8 0x072afb4dbccc in client_global_request_reply (type=,
seq=, ssh=0x72d84623780)
at /usr/src/usr.bin/ssh/ssh/../clientloop.c:463
gc = 0x72d4049de00
#9 0x072afb53012b in ssh_dispatch_run (ssh=0x72d84623780, mode=1,
done=0x72afb549810 ) at /usr/src/usr.bin/ssh/ssh/../dispatch.c:111
seqnr = 4294911664
type =
r =
#10 0x072afb5301ab in ssh_dispatch_run_fatal (ssh=0x72d84623780,
mode=-55632, done=0x0) at /usr/src/usr.bin/ssh/ssh/../dispatch.c:131
r =
#11 0x072afb4d9601 in client_process_buffered_input_packets (ssh=) at /usr/src/usr.bin/ssh/ssh/../clientloop.c:1182
No locals.
#12 client_loop (ssh=0x72d84623780, have_pty=0, escape_char_arg=92236,
ssh2_chan_id=) at /usr/src/usr.bin/ssh/ssh/../clientloop.c:1325
buf =
"cy\t\345ߍb\255\033q\005\242\vP\265/\263\b|\201\330X\354o\245\273\311\\^k*\253ѝTn\022<\025\261\244\a\342V6D[?\030\231.\001\264Xn\201\365\375H\373\021\255\256\247@\331W\247;P7\021\300~2e\362\005\264>\220\027\204\217\242\023\006\315eA\366\f\201\374\a\304*\211\235\071"
max_fd2 = 3
max_fd = 3
nalloc =
start_time = 92236.903928921995
r =
writeset =
readset =
len =
total_time =
ibytes =
obytes =
#13 0x072afb4d0384 in ssh_session2 (ssh=, pw=0x72d2e3d4800)
at /usr/src/usr.bin/ssh/ssh/../ssh.c:1966
id =
tun_fwd_ifname =
cp =
r =
devnull =
#14 main (ac=, av=) at
/usr/src/usr.bin/ssh/ssh/../ssh.c:1499
buf =
"/home/tbrown/.ssh\000\000\000\000\000\000\000}\r\001\000\022\000\v\000\340\231\035\000\000\000\000\000d\000\000\000\000\000\000\000\000\023\001\000\022\000\v\000\360\v\036\000\000\000\000\000\060\000\000\000\000\000\000\000^_\000\000\022\000\v\000@Q\020\000\000\000\000\000\060\000\000\000\000\000\000\000\215\271\000\000\022\000\v\000\060\364\024\000\000\000\000\000\320\000\000\000\000\000\000\000\031\322\000\000\022\000\v\000@Z\033\000\000\000\000\000\021\000\000\000\000\000\000\000\335\v\000\000\022\000\v\000\220\371\031\000\000\000\000\000\027\000\000\000\000\000\000\000\016*\000\000\022\000\v\000\020\302\r\000\000\000\000\000\060\000\000\000\000\000\000\000\362D\000\000\021\000\024\000\000"...
cname = '\000' , "\343l\000\000\020", '\000' , "\353l\000\000\020", '\000' , ".p\000\000\020",
'\000' , "\066p\000\000\020", '\000' ,
"\306q\000\000\020", '\000' , "\313q\000\000\020", '\000'
, "\311|\000\000\020", '\000' , "
\203\000\000\020", '\000' ...
conn_hash =
"@\003\244\227\263\017\204\273P\216[J\000:Z\355z\002\275\264\230-\345Q\000\064\267\225-\a\000\000^\215\177\v\375\025%n\210_\377\377\177\177\000\000ϻv\353-\a\000\000\230_\377\377\177\177\000"
want_final_pass =
opt_terminated =
config_test = 0
pw = 0x72d2e3d4800
Re: -current bsd.rd fails to boot on Thinkpad X1 5th gen
Hi, Same behaviour here with a Fujitsu Lifebook S752, although it only seems to affect RAMDISK_CD and not GENERIC.MP. I compiled both from a fresh tree and the latter boots fine, whereas the RD reboots in a loop just as shown below. On 13:24 Tue 24 Jul , Sebastian Benoit wrote: > Edd Barrett(e...@theunixzoo.co.uk) on 2018.07.24 11:20:57 +0100: > > Hi, > >=20 > > Went to upgrade my snap on my laptop today and got a reboot. It was > > printing some stuff before the reboot. I had to video the screen and > > pause it to see what it said: > >=20 > > ---8<--- > > ... > > wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0 > > fatal protection fault in supervisor mode > > ... > > dump to dev 17,1 not possible > > rebooting... > > here is the panic as text. > > last kernel i was running was > OpenBSD 6.3-current (GENERIC.MP) #128: Fri Jul 13 00:41:59 MDT 2018 > > =0Dboot> =1B[06;00H > \=08|=08/=08-=08\=08|=08/=08booting hd0a:/bsd: -=08\=08|=08/=08-=083470154\= > =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= > -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= > =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= > \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= > =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= > |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= > =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= > /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= > =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= > -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= > =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= > \=08|=08/=08-=08\=08|=08/=08-=08+1483776\=08|=08/=08-=08\=08|=08/=08-=08\= > =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= > -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= > =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= > \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= > =08-=08\=08|=08/=08-=08\=08|=08/=08+3891832-=08\=08|=08/=08-=08\=08|=08/=08= > -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= > =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= > \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= > =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= > |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= > =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= > /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= > =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= > -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|= > =08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= > \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/= > =08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08+0+593920|=08 [365272/=08-=08\= > =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= > -=08\=08+111+437280|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= > -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08+290676\=08|=08/=08-=08= > \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08]=3D0xa0e260 > /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08entry point at 0x1000158 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.= > org > > OpenBSD 6.3-current (RAMDISK_CD) #127: Mon Jul 23 19:33:54 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > real mem =3D 8572895232 (8175MB) > avail mem =3D 8309293056 (7924MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xfcd20 (81 entries) > bios0: vendor American Megatrends Inc. version "'V1.00.B20'" date 05/19/2009 > bios0: empty empty > acpi0 at bios0: rev 0 > acpi0: tables DSDT FACP APIC MCFG OEMB HPET > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, 1995.28 MHz > cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE= > 36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,= > VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MEL= > TDOWN > cpu0: 6MB 64b/line 16-way L2 cache > cpu0: apic clock running at 332MHz > cpu0: mwait min=3D64, max=3D64, C-substates=3D0.2.2.2, IBE > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > ioapic0 at mainbus0: apid 4 pa 0xfec0,
Re: Bus error in smtpctl spf walk
Hi Otto, Ugh! They have an "SPF record" and causes the error, your patch solves the issue. This will also prevent similar error(s) from other offenders, so FWIW OK mestre@ On 13:13 Tue 06 Mar , Otto Moerbeek wrote: > On Tue, Mar 06, 2018 at 10:46:23AM +0100, Jan Johansson wrote: > > > >Synopsis: Bus error in smtpctl spf walk (on certain domains) > > >Category: user > > >Environment: > > System : OpenBSD 6.3 > > Details : OpenBSD 6.3-beta (GENERIC.MP) #26: Fri Mar 2 22:56:04 > > MST 2018 > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > Got a mail with "Return-Path: bounces+abcd1...@sendgrid.meetup.com" > > and wanted to add it to my white list but smtpctl spf walk says "Bus > > error". Other domains like facebookmail.com works without problem. > > http://www.kitterman.com/spf/validate.html seems to think > > sendgrid.meetup.com has a valid record. > > > > >How-To-Repeat: > > echo sendgrid.meetup.com | smtpctl spf walk > > > > >Fix: > > Not known > > Try this, > > -Otto > > Index: spfwalk.c > === > RCS file: /cvs/src/usr.sbin/smtpd/spfwalk.c,v > retrieving revision 1.5 > diff -u -p -r1.5 spfwalk.c > --- spfwalk.c 26 Jan 2018 08:00:54 - 1.5 > +++ spfwalk.c 6 Mar 2018 12:12:42 - > @@ -140,6 +140,8 @@ dispatch_txt(struct dns_rr *rr) > char *end; > ssize_t n; > > + if (rr->rr_type != T_TXT) > + return; > n = parse_txt(rr->rr.other.rdata, rr->rr.other.rdlen, buf, sizeof(buf)); > if (n == -1 || n == sizeof(buf)) > return; >
Re: openssl: s_time needs dns pledge promise
ok mestre@
On 19:07 Wed 01 Nov , Scott Cheloha wrote:
> Hi,
>
> The following (and similar invocations) gets SIGABRT'd:
>
> openssl s_time -connect openbsd.org:443
>
> BIO_set_conn_hostname(3), or whatever BIO_ctrl(3) is doing
> underneath, tries to resolve your target host and the process
> gets signaled when it enters socket(2).
>
> Adding "dns" to the pledge(2) promise corrects this.
>
> It looks like this has been broken since ~2015 but I have no
> release machines handy to confirm.
>
> --
> Scott Cheloha
>
> Index: usr.bin/openssl/s_time.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/s_time.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 s_time.c
> --- usr.bin/openssl/s_time.c 20 Jan 2017 08:57:12 - 1.17
> +++ usr.bin/openssl/s_time.c 1 Nov 2017 23:30:23 -
> @@ -254,7 +254,7 @@ s_time_main(int argc, char **argv)
> int ver;
>
> if (single_execution) {
> - if (pledge("stdio rpath inet", NULL) == -1) {
> + if (pledge("stdio rpath inet dns", NULL) == -1) {
> perror("pledge");
> exit(1);
> }
>
Re: SSH ~& command crash with a coredump
committed, thanks for the report Gregoire! On 01:34 Fri 23 Jun , Jeremie Courreges-Anglas wrote: > Gr??goire Jadi <gj...@omecha.info> writes: > > > n 06/21/17 12:16, Ricardo Mestre wrote: > >> Hi, > >> > >> I can confirm this issue, and the diff below seems to solve it for me. > >> > >> Could you please test it and let us know if it works on your side? > > > > It does fix the issue. Thanks you. > > > >> > >> Reason: In clientloop.c during client_loop() this function calls > >> client_simple_escape_filter() which then calls process_escapes() which in > >> turn > >> fork()s the process. That being said, the pledge inside client_loop which > >> applies to this code path lacks the proc promise and therefore aborts ssh. > > At first I couldn't reproduce the crash since I'm using "ControlMaster > auto". Since all the other pledge calls specify "proc", I don't think > it's a big drawback. ok jca@
Re: SSH ~& command crash with a coredump
Hi,
I can confirm this issue, and the diff below seems to solve it for me.
Could you please test it and let us know if it works on your side?
Reason: In clientloop.c during client_loop() this function calls
client_simple_escape_filter() which then calls process_escapes() which in turn
fork()s the process. That being said, the pledge inside client_loop which
applies to this code path lacks the proc promise and therefore aborts ssh.
Index: clientloop.c
===
RCS file: /cvs/src/usr.bin/ssh/clientloop.c,v
retrieving revision 1.299
diff -u -p -u -r1.299 clientloop.c
--- clientloop.c31 May 2017 09:15:42 - 1.299
+++ clientloop.c21 Jun 2017 10:14:26 -
@@ -1246,7 +1246,7 @@ client_loop(int have_pty, int escape_cha
} else {
debug("pledge: network");
- if (pledge("stdio unix inet dns tty", NULL) == -1)
+ if (pledge("stdio unix inet dns proc tty", NULL) == -1)
fatal("%s pledge(): %s", __func__, strerror(errno));
}
