su(1): bad auth_approval(3) failure handling

Hello, auth_approval(3) doesn't always set errno(2) on failure: --- usr.bin/su/su.c.origSat Dec 7 20:23:21 2019 +++ usr.bin/su/su.c Fri Oct 30 14:38:11 2020 @@ -358,7 +358,7 @@ main(int argc, char **argv) err(1, "pledge"); if (pwd->pw_uid && auth_approval(as

ripd(8) fails on P2P links

Hi, according to the comment in usr.sbin/ripd/packet.c, ripd(8) fails to find the interface on which a packet was received when the source and destination addresses of the interface do not share the same subnet. Here is a patch: http://www.durlej.net/tmp/ripd-p2p.diff Kind regards, Piotr

Re: ripd(8) fails on P2P links

W dniu 21.11.2016 15:20, Martin Pieuchot napisał(a): On 20/11/16(Sun) 08:27, Piotr Durlej wrote: Hi, according to the comment in usr.sbin/ripd/packet.c, ripd(8) fails to find the interface on which a packet was received when the source and destination addresses of the interface do not share

execve(2) man page corrections

diff -ru src.orig/lib/libc/sys/execve.2 src/lib/libc/sys/execve.2 --- src.orig/lib/libc/sys/execve.2 Wed Jul 29 00:48:31 2015 +++ src/lib/libc/sys/execve.2 Sat Mar 26 20:30:51 2016 @@ -258,6 +258,8 @@ The new process file does not exist. .It Bq Er ELOOP Too many symbolic links were encou

isunordered(3) man page inconsistent with implementation

Hi, according to the man page: The isunordered() macro takes arguments x and y and returns non-zero if and only if neither x nor y are NaNs. According to math.h: #define isunordered(x, y) (isnan(x) || isnan(y)) The implementation seems correct. Piotr

ftp(1) not handling write(2) errors when sending files

ftp(1) is not handling write(2) errors correctly when sending files. The errors are ignored, and ftp(1) continues to read the source file and updates the progress bar. To reproduce: start an FTP transfer using the put command. While the transfer is in progress, kill the server process handling

find(1) shows bogus error messages

To reproduce: $ /usr/bin/find /bin /nonexistent -ls > /dev/null find: /nonexistent: Undefined error: 0 $ /usr/bin/find /bin /nonexistent > /dev/null find: /nonexistent: Operation not supported by device $ uname -mrsv OpenBSD 5.6 GENERIC#2 i386 $ Here is a patch: --- usr.bin/find/find.c.old

Applying binary patches sets /bsd* executable

Hi, before running syspatch(8): -rw-r--r-- 1 root wheel 10751939 Jun 1 00:45 bsd -rw-r--r-- 1 root wheel 9431142 Jun 1 00:45 bsd.rd -rw-r--r-- 1 root wheel 10683954 Jun 1 00:45 bsd.sp after syspatch(8): -rwxr-xr-x 1 root wheel 10756231 Jun 1 13:42 bsd -rw-r--r-- 1 root

sysctl(2) man page typo correction

--- lib/libc/sys/sysctl.2.old Tue Nov 6 10:08:56 2018 +++ lib/libc/sys/sysctl.2 Tue Nov 6 10:09:03 2018 @@ -256,7 +256,7 @@ .It Dv FS_POSIX_SETUID Ta "integer" Ta "yes" .El .Bl -tag -width "123456" -.It Dv FS_POSIX_SETUID Pq Va fx.posix.setuid +.It Dv FS_POSIX_SETUID Pq Va fs.posix.se

[PATCH] Fix vacation(1) handling of from addresses in angle brackets

vacation(1) doesn't work: smtpd[39062]: ccca6c1750c9b32e smtp failed-command command="RCPT TO:<> " result="501 5.1.3 Recipient address syntax error" --- vacation.c | 13 + 1 file changed, 13 insertions(+) diff --git a/vacation.c b/vacation.c index 7105f56..72f02f7 100644 --- a/vaca

[PATCH] Remove the no longer supported ! command from less.hlp

--- less.hlp | 1 - 1 file changed, 1 deletion(-) diff --git a/less.hlp b/less.hlp index 2bc53df..f89f87b 100644 --- a/less.hlp +++ b/less.hlp @@ -96,7 +96,6 @@ ___<_n_a_m_e_> Display the setting of an option, by name. +_c_m_d Execute the less cmd each t

[PATCH 1/3] Add missing clear(1) man page

--- usr.bin/tput/Makefile | 1 + usr.bin/tput/clear.1 | 163 ++ 2 files changed, 164 insertions(+) create mode 100644 usr.bin/tput/clear.1 diff --git a/usr.bin/tput/Makefile b/usr.bin/tput/Makefile index 7b261e36c7f..c966ab1acee 100644 --- a/usr.bin/tpu

[PATCH 2/2] Handle short writes in cp(1)

Handle short writes in cp(1) --- bin/cp/utils.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/bin/cp/utils.c b/bin/cp/utils.c index 347081151f2..40265fce7f7 100644 --- a/bin/cp/utils.c +++ b/bin/cp/utils.c @@ -149,11 +149,16 @@ copy_file(FTSENT *entp, int exists)

[PATCH 1/2] Handle ftruncate(2) errors in dd(1)

Handle ftruncate(2) errors in dd(1) --- bin/dd/dd.c | 5 - bin/dd/dd.h | 3 ++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/bin/dd/dd.c b/bin/dd/dd.c index d07d935bde7..4b0d99144e2 100644 --- a/bin/dd/dd.c +++ b/bin/dd/dd.c @@ -161,7 +161,8 @@ setup(void) * kinds o

[PATCH] add a link to the 7.5 errata

--- security.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/security.html b/security.html index 38b427bb9..eb7f9e0e4 100644 --- a/security.html +++ b/security.html @@ -83,7 +83,8 @@ For security advisories for specific releases, click below: 7.1, 7.2, 7.3, -7.4. +7.4

Outstanding patches

c.info/?l=openbsd-bugs&m=171407191132356&w=2 Kind regards, Piotr Durlej

Extraneous newline in sendmail(8) error messages

Hello, sendmail(8) usually prints an extraneous newline after an (E)SMTP error message, here's a patch: --- usr.sbin/smtpd/enqueue.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/usr.sbin/smtpd/enqueue.c b/usr.sbin/smtpd/enqueue.c index 51616d0d590..70a25e4a1f0 100644

mail(1) doesn't wait for sendmail(8) termination

Hello, probably mail(1) should always wait for sendmail(8) termination in order to prevent any possible sendmail error messages from being intermixed with subsequent terminal output. --- usr.bin/mail/send.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/usr.bin/mail/sen

[PATCH] getty(8): Fix the 'dx' capability (DECCTLQ)

--- libexec/getty/subr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libexec/getty/subr.c b/libexec/getty/subr.c index 49b7f3d3ae5..f036dec0803 100644 --- a/libexec/getty/subr.c +++ b/libexec/getty/subr.c @@ -307,9 +307,9 @@ setflags(int n) CLR(lflag, EC

OpenBSD 5.0 sl(4) crash

Hi, I just want to make sure this hasn't gone unnoticed: http://marc.info/?l=openbsd-bugs&m=131179618801709&w=2 http://marc.info/?l=openbsd-bugs&m=131180575015325&w=2 I was able to reproduce this bug on OpenBSD 5.0. # cat /etc/rc.conf.local ntpd_flags= # enabled during install pf=N

Re: OpenBSD 5.0 sl(4) crash

Piotr Durlej wrote: Hi, I just want to make sure this hasn't gone unnoticed: http://marc.info/?l=openbsd-bugs&m=131179618801709&w=2 http://marc.info/?l=openbsd-bugs&m=131180575015325&w=2 I was able to reproduce this bug on OpenBSD 5.0. # cat /etc/rc.conf.local ntpd_fl

SIOCDIFADDR_IN6 crash

I had a 5.1/i386 kernel crash: ddb> show panic the kernel did not panic ddb> trace prelist_remove(d13d3600,0,60,d09befa0,2) at prelist_remove+0xb4 in6_control(d9c7fee0,81206919,d142d800,d1671400,0) at in6_control+0xbcc ifioctl(d9c7fee0,81206919,d142d800,d544aa70,d9c7fee0) at ifioctl+0x216 sys_ioc

ls(1) prints non-ascii characters as the character '?'

ls(1) prints non-ascii characters as the character '?' despite of LC_ALL and/or LC_CTYPE being set in the environment. Here is a diff: http://www.durlej.net/diffs/ls.diff

Two simple softraid(4) patches

Hi, these two simple patches allow an softraid(4) RAID 1 array to be correctly rebuild. http://www.durlej.net/sr-iosz.diff http://www.durlej.net/sr-szal.diff Without sr-iosz.diff, the system may incorrectly compute the offset of the final transfer during rebuild. This will cause subsequent r

Negative round-trip times may hang ping(8)

Both negative and large positive round-trip times may hang ping(8) because of integer overflows in the statistics code. This patch will cause ping not to print statistics if a negative RTT is encountered or an overflow occurs during accumulation of statistics: http://www.durlej.net/pingneg.diff

ping(8) does not print it's header line if the output is redirected

ping(8) does not print it's header line if the standard output is not a tty(4) and the target host does not respond. To reproduce: $ ping -c1 -w1 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes --- 10.0.0.1 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss $ ping

sl(4) race condition

Apparently there are at least two interrupt race conditions between the sl(4) driver and the generic network code. This crash was observed on an i386 running a GENERIC 4.9 kernel: http://www.durlej.net/sl-crash-out And the following one is from a custom 4.9 kernel. I hope it is still useful: ht

Re: sl(4) race condition

On Wed, Jul 27, 2011 at 09:48:27PM +0200, Piotr Durlej wrote: > Running a ping(8) flood through a router with a sl interface seems to be > sufficient to reproduce the crash. > Of course the traffic must pass the slip interface to trigger the bug. Regards, Piotr

[PATCH] Print pathnames in sort(1) error messages

before: $ sort -u /usr/share/dict/* sort: Is a directory after: $ ./sort -u /usr/share/dict/* sort: /usr/share/dict/papers: Is a directory $ --- file.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/file.c b/file.c index a19ffa0..1df6b7e 100644 --- a/file.c +++ b/f