src/sys/dev, branch releng/10.3

Fix multiple small kernel memory disclosures. [EN-18:04.mem]

2018-04-04T05:43:03Z

Reported by: Ilja van Sprundel Approved by: so Security: CVE-2018-6919 Security: FreeBSD-EN-18:04.mem

Fix vt console memory disclosure. [SA-18:04.vt]

2018-04-04T05:33:56Z

Bump newvers.sh and UPDATING for today's patches. Submitted by: emaste Reported by: Dr Silvio Cesare of InfoSect Approved by: so Security: CVE-2018-6917 Security: FreeBSD-SA-18:04.vt Sponsored by: The FreeBSD Foundation

Fix heimdal KDC-REP service name validation vulnerability [SA-17:05]

2017-07-12T08:07:55Z

Boot compatibility improvements with Azure VMs. [EN-17:06] Approved by: so

Fix multiple vulnerabilities of ntp. [SA-17:03]

2017-04-12T06:24:35Z

Xen migration enhancements. [EN-17:05] Approved by: so

Release 6 errata notices for 10.3-RELEASE, all related to Microsoft Hyper-V.

2016-08-12T04:01:16Z

Submitted by: Dexuan Cui , gjb Approved by: so

- Use unsigned version of min() when handling arguments of SETFKEY ioctl.

2016-05-17T22:28:27Z

- Validate that user supplied control message length in sendmsg(2) is not negative. Security: SA-16:18 Security: CVE-2016-1886 Security: SA-16:19 Security: CVE-2016-1887 Submitted by: C Turt Approved by: so

MFC [Hyper-V]: r296028

2016-03-01T02:07:14Z

hyperv: Wait 5 seconds for hyperv result, instead of 500ms This addresses various devices (network, stoarge) attach failure. Approved by: re (gjb) Reported by: Hongxiong Xian Tested by: Hongxiong Xian Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5435

MFC r295944:

2016-02-29T15:45:43Z

nvme: fix intx handler to not dereference ioq during initialization This was a regression from r293328, which deferred allocation of the controller's ioq array until after interrupts are enabled during boot. Approved by: re (gjb) Sponsored by: Intel

MFC: r295906

2016-02-26T00:09:50Z

Fix and clean up usage of DMA and TSO segments: - At Intel it is believed that most of their products support "only" 40 DMA segments so lower {EM,IGB}_MAX_SCATTER accordingly. Actually, 40 is more than plenty to handle full size TSO packets so it doesn't make sense to further distinguish between MAC variants that really can do 64 DMA segments. Moreover, capping at 40 DMA segments limits the stack usage of {em,igb}_xmit() that - given the rare use of more than these - previously hardly was justifiable, while still being sufficient to avoid the problems seen with em(4) and EM_MAX_SCATTER set to 32. - In igb(4), pass the actually supported TSO parameters up the stack. Previously, the defaults set in if_attach_internal() were applied, i. e. a maximum of 35 TSO segments, which made supporting more than these in the driver pointless. However, this might explain why no problems were seen with IGB_MAX_SCATTER at 64. - In em(4), take the 5 m_pullup(9) invocations performed by em_xmit() in the TSO case into account when reporting TSO parameters upwards. In the worst case, each of these calls will add another mbuf and, thus, the requirement for an additional DMA segment. So for best performance, it doesn't make sense to advertize a maximum of TSO segments that typically will require defragmentation in em_xmit(). Again, this leaves enough room to handle full size TSO packets. - Drop TSO macros from if_lem.h given that corresponding MACS don't support TSO in the first place. Reviewed by: erj, sbruno, jeffrey.e.pieper_intel.com Approved by: re (gjb)

MFC r295830

2016-02-25T22:07:32Z

Remove dead code. Code Cleanup. Improve clarity in debug messages Approved by:re (marius)