OpenBSD src changes summary for 2017-03-17
==========================================

distrib/sets                            etc/Makefile
etc/rc.d/dhcrelay6                      lib/libc
lib/libutil                             sys/dev/usb
sys/kern                                sys/net
sys/netinet                             sys/sys
sys/uvm                                 usr.bin/mandoc
usr.bin/tmux                            usr.bin/whois
usr.sbin                                usr.sbin/dhcrelay6
usr.sbin/smtpd                          

== distrib =========================================================== 01/06 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib

sets

  ~ lists/base/mi                         ~ lists/man/mi

  > Enable dhcrelay6(8).
  > ok deraadt@ (rzalamena@)

== etc =============================================================== 02/06 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc

Makefile

  ~ Makefile                              

  > Enable dhcrelay6(8).
  > ok deraadt@ (rzalamena@)

rc.d/dhcrelay6

  + rc.d/dhcrelay6                        

  > Enable dhcrelay6(8).
  > ok deraadt@ (rzalamena@)

== lib =============================================================== 03/06 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib

libc

  ~ stdio/asprintf.c                      ~ stdio/fgetln.c
  ~ stdio/open_memstream.c                ~ stdio/vasprintf.c

  > Use recallocarray() to avoid leaving detritus in memory when resizing
  > buffers.  We don't bother doing this for objects containing pointers,
  > but focus on controllable data.
  > ok millert (deraadt@)

  ~ gen/fts.c                             

  > recallocarray() the string buffer, to avoid leaving such contents
  > around in the address space.  Don't bother doing so for the buffer
  > which contains aslr'd pointers...
  > ok millert (deraadt@)

  ~ stdio/fvwrite.c                       

  > Use recallocarray() to avoid leaving detritus in memory when resizing
  > the string buffer used by asprintf() and vasprintf().  OK deraadt@
  > (millert@)

  ~ stdlib/malloc.3                       

  > Strengthen description of recallocarray(3) behaviour, hoping that readers
  > make the behaviour -> use case connection.
  > help from jmc and jsing (deraadt@)

  ~ stdlib/malloc.3                       

  > remove unneccessary macro; (jmc@)

libutil

  ~ imsg-buffer.c                         

  > Grow buffers using recallocarray, to avoid the potential dribble that
  > the standard realloc*() functions can leave behind.  imsg buffers are
  > sometimes used in protocol stacks which require some secrecy, and layering
  > violations would be needed to resolve this issue otherwise.
  > Discussed with many. (deraadt@)

== sys =============================================================== 04/06 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys

dev/usb

  ~ usbdi.c                               

  > ubcmtp(4) works because of a use-after-free.  Many more drivers are
  > certainly doing the same.
  > So revert r1.85 for the moment, we're too close from the release and
  > these bugs have been there for years.
  > Regression reported by tb@ on bugs@ (mpi@)

  ~ ubcmtp.c                              

  > More debug goo to help tracking the use-after-free. (mpi@)

kern

  ~ uipc_socket.c                         ~ uipc_socket2.c

  > Revert the NET_LOCK() and bring back pf's contention lock for release.
  > For the moment the NET_LOCK() is always taken by threads running under
  > KERNEL_LOCK().  That means it doesn't buy us anything except a possible
  > deadlock that we did not spot.  So make sure this doesn't happen, we'll
  > have plenty of time in the next release cycle to stress test it.
  > ok visa@ (mpi@)

net

  ~ if.c                                  ~ if_pflow.c
  ~ pf.c                                  ~ pf_ioctl.c
  ~ pf_norm.c                             ~ pfvar.h

  > Revert the NET_LOCK() and bring back pf's contention lock for release.
  > For the moment the NET_LOCK() is always taken by threads running under
  > KERNEL_LOCK().  That means it doesn't buy us anything except a possible
  > deadlock that we did not spot.  So make sure this doesn't happen, we'll
  > have plenty of time in the next release cycle to stress test it.
  > ok visa@ (mpi@)

netinet

  ~ ip_mroute.c                           

  > Be more strict on all route iterations, lets always make sure that we
  > are not going to get a unicast route by accident.
  > ok mpi@ (rzalamena@)

  ~ ip_carp.c                             

  > carp(4) code is always executed in the 'softnet' thread, so remove
  > unneeded splnet()/splx() dance.
  > ok mikeb@, bluhm@ (mpi@)

sys

  ~ systm.h                               

  > Revert the NET_LOCK() and bring back pf's contention lock for release.
  > For the moment the NET_LOCK() is always taken by threads running under
  > KERNEL_LOCK().  That means it doesn't buy us anything except a possible
  > deadlock that we did not spot.  So make sure this doesn't happen, we'll
  > have plenty of time in the next release cycle to stress test it.
  > ok visa@ (mpi@)

uvm

  ~ uvm_vnode.c                           

  > Revert the NET_LOCK() and bring back pf's contention lock for release.
  > For the moment the NET_LOCK() is always taken by threads running under
  > KERNEL_LOCK().  That means it doesn't buy us anything except a possible
  > deadlock that we did not spot.  So make sure this doesn't happen, we'll
  > have plenty of time in the next release cycle to stress test it.
  > ok visa@ (mpi@)

== usr.bin =========================================================== 05/06 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin

mandoc

  ~ man_html.c                            ~ mdoc_html.c

  > Fix regression in mdoc_html.c 1.150, man_html 1.87:
  > For .Sh, .Ss, .SH, .SS, only write selflink if an id could be constructed.
  > Crash reported by Raf Czlonka <rczlonka at gmail dot com>,
  > analysis of root cause by natano@ (schwarze@)

  ~ man.cgi.8                             

  > Update HISTORY and AUTHORS: we no longer use SQLite.
  > Outdated information reported by an Anonymous Coward on undeadly.org.
  > (schwarze@)

  ~ apropos.1                             ~ man.1

  > Document man(1) section selection priority,
  > and correct description of apropos(1) output search order.
  > Suggested by tb@. (schwarze@)

tmux

  ~ window-choose.c                       

  > Add h and l for collapse and expand in choose mode with vi(1) keys, from
  > Gregory Pakosz. (nicm@)

  ~ utf8.c                                ~ cmd-show-messages.c

  > Fix a couple of argument types. (nicm@)

whois

  ~ whois.c                               

  > choose_server() does not always return malloc'd memory so pass
  > in a pointer that gets filled in when there is something to free.
  > Noticed by sthen@ when looking up a numeric address. (millert@)

== usr.sbin ========================================================== 06/06 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin

usr.sbin

  ~ Makefile                              

  > Enable dhcrelay6(8).
  > ok deraadt@ (rzalamena@)

dhcrelay6

  + Makefile                              + bpf.c
  + dhcp.h                                + dhcpd.h
  + dhcrelay6.8                           + dhcrelay6.c
  + dispatch.c                            + log.c
  + log.h                                 + packet.c

  > Import the DHCPv6 relay implementation.
  > This code was based on the dhcrelay(8) daemon and shares a lot of the
  > structures and functions. This daemon implements the following RFCs:
  > * RFC 3315 Section 20: Relay Agent Behavior
  > * RFC 4649: Relay Agent Remote-ID option
  > * RFC 6221: Lightweight DHCPv6 Relay Agent (rzalamena@)

  ~ dhcrelay6.8                           ~ dhcrelay6.c

  > various tweaks; ok rzalamena (jmc@)

smtpd

  ~ iobuf.c                               

  > realloc() -> recallocarray().
  > use calloc() for initial allocation.
  > prodded by deraadt@ ok gilles@ (eric@)

  ~ mproc.c                               

  > switch to recallocarray() and remove useless pre-allocation.
  > prodded by deraadt@ ok gilles@ (eric@)

===============================================================================
_______________________________________________
odc mailing list
[email protected]
http://www.squish.net/mailman/listinfo/odc

Reply via email to