OpenBSD src changes summary for 2016-02-03
==========================================

distrib/sets                            sbin/dhclient
share/man                               sys/arch/amd64/amd64
sys/arch/i386/i386                      sys/dev/pci
sys/dev/pv                              sys/scsi
usr.bin/less                            usr.bin/tail
usr.bin/vi                              usr.sbin
usr.sbin/dhcpd                          usr.sbin/dhcrelay
usr.sbin/pkg_add                        usr.sbin/smtpd
usr.sbin/tcpdump                        

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

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

sets

  ~ lists/base/md.amd64                   ~ lists/base/md.i386
  ~ lists/man/mi                          

  > sync (jsg@)

== sbin ============================================================== 02/06 ==

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

dhclient

  ~ packet.c                              

  > be very careful accepting packets via bpf. First check that the
  > fixed part of the IP header is completely present before using its
  > header length field.  Then use the data in the IP header to ensure
  > the entire IP packet is present. Then check that the entire UDP header
  > is present. Then use the data in the UDP header to ensure all the
  > data it thinks is present is actually present.
  > Started when tj@ and a few others noticed ISC "DHCP CVE-2015-8605:
  > UDP payload length not properly checked".
  > ok sthen@ henning@ (krw@)

== share ============================================================= 03/06 ==

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

man

  ~ man4/Makefile                         

  > hookup dwctwo.4 (jasper@)

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

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

arch/amd64/amd64

  ~ amd64_mem.c                           ~ cacheinfo.c
  ~ cpu.c                                 ~ identcpu.c

  > Test cpuid_level or ci->ci_pnfeatset before using a CPUID leaf; some BIOSes
  > can disable leaves that CPU feature flags would seem to imply.  Corrects
  > signal delivery on systems where the AVX leaf is disabled.
  > report and debugging help from Marcus MERIGHI (mcmer-openbsd (at) tor.at)
  > ok kettenis@ (guenther@)

arch/i386/i386

  ~ cpu.c                                 

  > Test cpuid_level or ci->ci_pnfeatset before using a CPUID leaf; some BIOSes
  > can disable leaves that CPU feature flags would seem to imply.  Corrects
  > signal delivery on systems where the AVX leaf is disabled.
  > report and debugging help from Marcus MERIGHI (mcmer-openbsd (at) tor.at)
  > ok kettenis@ (guenther@)

dev/pci

  ~ drm/radeon/radeon_kms.c               

  > Prevent efifb(4) from attaching if we're the console.
  > Unfortunately, making this decision in radeondrm_attachhook() is too late
  > because at that point efifb(4) would have already been attached.  This
  > means
  > that if we decide to bail in radeondrm_attachhook() we may end up without
  > a glass console.  That may happen for example if the firmware package
  > has not been installed.  I'm still looking for a solution for that problem.
  > ok jsg@ (kettenis@)

dev/pv

  ~ vmt.c                                 

  > Increase the RPC buffer once more to 4096 bytes.  The guestinfo.ovfEnv
  > mechanism is used to configure VMs in the VMware vSphere world:
  > instead of using individual key-value guestinfo.* properties, it uses
  > the guestinfo.ovfEnv value to pass an enterprise-compliant XML file
  > that includes key-value properties.  This file can be rather large,
  > especially with comments, but 4k ought to be enough for anybody.
  > Also change a stack buffer to malloc'ed memory in the ioctl path.
  > OK mikeb@ (reyk@)

scsi

  ~ sd.c                                  

  > When accessing the scsi link of a scsi disk, use a variable "sc_link"
  > everywhere.  This is the first step to fix a use after free of the
  > sc_link when the disk detaches.  If a function gets a scsi transfer,
  > the scsi link is always valid.  Call this variable "link" consistently.
  > OK krw@ (bluhm@)

  ~ sd.c                                  

  > Do not access the scsi link of the disk at the beginning of sdopen()
  > and sdminphys() if the scsi disk is dying.  The memory of the link
  > may have been freed already.
  > OK krw@ (bluhm@)

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

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

less

  ~ optfunc.c                             

  > Rename a local var so that we can call the global message buffer msg.
  > ok nicm, tb (mmcc@)

tail

  ~ tail.c                                

  > fix off-by-one in argument parsing
  > ok martijn@ (halex@)

vi

  ~ cl/cl_main.c                          ~ common/main.c
  ~ common/mem.h                          

  > Remove needless alias macros for malloc and calloc. No binary change. I
  > got this upstreamed a few weeks ago.
  > ok tb (less a few style tweaks), martijn (who suggested style tweaks)
  > (mmcc@)

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

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

usr.sbin

  ~ Makefile                              

  > Enable hostctl (only i386 and amd64 for now).
  > OK mikeb@ jsg@ krw@ ajacoutot@ (reyk@)

dhcpd

  ~ packet.c                              

  > be very careful accepting packets via bpf. First check that the
  > fixed part of the IP header is completely present before using its
  > header length field.  Then use the data in the IP header to ensure
  > the entire IP packet is present. Then check that the entire UDP header
  > is present. Then use the data in the UDP header to ensure all the
  > data it thinks is present is actually present.
  > Started when tj@ and a few others noticed ISC "DHCP CVE-2015-8605:
  > UDP payload length not properly checked".
  > ok sthen@ henning@ (krw@)

dhcrelay

  ~ packet.c                              

  > be very careful accepting packets via bpf. First check that the
  > fixed part of the IP header is completely present before using its
  > header length field.  Then use the data in the IP header to ensure
  > the entire IP packet is present. Then check that the entire UDP header
  > is present. Then use the data in the UDP header to ensure all the
  > data it thinks is present is actually present.
  > Started when tj@ and a few others noticed ISC "DHCP CVE-2015-8605:
  > UDP payload length not properly checked".
  > ok sthen@ henning@ (krw@)

pkg_add

  ~ OpenBSD/Delete.pm                     ~ OpenBSD/PackingElement.pm

  > update the font cache by running fc-cache after removing packages
  > with @fontdir markers
  > ok espie@ (robert@)

smtpd

  ~ bounce.c                              

  > Use "esc_class" to classify bounce type instead of "errorline" as
  > we no longer prepend status code to "errorline". Fixes mismatch
  > between DSN's subject line and its content.
  > Ok jung@ gilles@ millert@ (sunil@)

  ~ enqueue.c                             ~ smtpctl.c

  > NULL initialize two file pointers to make it more obvious when reading that
  > they can't end up uninitialized after the mkstemp/fdopen dance (gilles@)

  ~ filter.c                              

  > When a filter rejects a message content, report immediatly to the
  > smtp session. Simplify code while here.
  > ok gilles@ jung@ (eric@)

  ~ smtp_session.c                        

  > tell filters to rollback the current transaction if MAIL or EOM fails
  > ok gilles@ jung@ (eric@)

  ~ smtp_session.c                        

  > Add helpers function to talk to the queue. Make the code simpler.
  > ok gilles@ sunil@ (eric@)

tcpdump

  ~ print-802_11.c                        

  > Make tcpdump show 802.11 control frames.
  > ok kettenis@, and help from David Vasek (thanks!) (stsp@)

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

Reply via email to