FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.3.0 2018-03-29T02:50:57Z 2018-03-29T02:50:57Z Eitan Adler eadler@FreeBSD.org 2018-03-29T02:50:57Z urn:sha1:4ab2e064d7950be84256d671a7ae93f87cc6aa36 This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code. Revert with prejudice. This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes. Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes. Requested by: gjb (re) 2018-03-27T17:51:45Z Brooks Davis brooks@FreeBSD.org 2018-03-27T17:51:45Z urn:sha1:73d68d7b942279aa256dfbc442ea16322082c72d Fix FSACTL_GET_NEXT_ADAPTER_FIB under 32-bit compat. This includes FSACTL_LNX_GET_NEXT_ADAPTER_FIB. Reviewed by: cem Obtained from: CheriBSD Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14672 2018-03-14T03:19:51Z Eitan Adler eadler@FreeBSD.org 2018-03-14T03:19:51Z urn:sha1:be5d0b9566b13fdf8cabebb63334cbec12bfc409 These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg 2018-03-05T06:47:28Z Eitan Adler eadler@FreeBSD.org 2018-03-05T06:47:28Z urn:sha1:faec58da3b51d7cc2f67d04333ededa54e8e9bb9 Remove a PCI ID for a raid controller from Adaptec that was planned, but never released. Since no real hardware was released with this ID, just drop it from the aacraid driver. This paves the path for future drivers for hardware that actually has this ID. Submitted by: Scott Benesh from Microsemi. Differential Revision: https://reviews.freebsd.org/D8377 MFC After: 3 days 2017-04-14T15:06:16Z Andriy Gapon avg@FreeBSD.org 2017-04-14T15:06:16Z urn:sha1:d71067f5192cc4c989cfe9e5ad54228540467d00 2017-03-23T08:10:25Z Andriy Gapon avg@FreeBSD.org 2017-03-23T08:10:25Z urn:sha1:7d4ff877c40d3230b6579a52b02630a2bb7e4ed8 2017-03-23T06:40:20Z Alexander Motin mav@FreeBSD.org 2017-03-23T06:40:20Z urn:sha1:6352900b3df2d8e5409dbf52d6b3d6c494817605 Always null-terminate ccb_pathinq.(sim_vid|hba_vid|dev_name) The sim_vid, hba_vid, and dev_name fields of struct ccb_pathinq are fixed-length strings. AFAICT the only place they're read is in sbin/camcontrol/camcontrol.c, which assumes they'll be null-terminated. However, the kernel doesn't null-terminate them. A bunch of copy-pasted code uses strncpy to write them, and doesn't guarantee null-termination. For at least 4 drivers (mpr, mps, ciss, and hyperv), the hba_vid field actually overflows. You can see the result by doing "camcontrol negotiate da0 -v". This change null-terminates those fields everywhere they're set in the kernel. It also shortens a few strings to ensure they'll fit within the 16-character field. PR: 215474 Reported by: Coverity CID: 1009997 1010000 1010001 1010002 1010003 1010004 1010005 CID: 1331519 1010006 1215097 1010007 1288967 1010008 1306000 CID: 1211924 1010009 1010010 1010011 1010012 1010013 1010014 CID: 1147190 1010017 1010016 1010018 1216435 1010020 1010021 CID: 1010022 1009666 1018185 1010023 1010025 1010026 1010027 CID: 1010028 1010029 1010030 1010031 1010033 1018186 1018187 CID: 1010035 1010036 1010042 1010041 1010040 1010039 2016-05-03T03:41:25Z Pedro F. Giffuni pfg@FreeBSD.org 2016-05-03T03:41:25Z urn:sha1:453130d9bfc1c6d68b366dfcb041689d69f81295 Most affect comments, very few have user-visible effects. 2016-04-26T20:59:21Z Conrad Meyer cem@FreeBSD.org 2016-04-26T20:59:21Z urn:sha1:0f752e9f7b50061af0418df47c15063affef3952 strcpy(3) emits a trailing nul byte, trampling fields after the intended destination. Instead, use strncpy(3), intentionally leaving these fields not nul-terminated. Reported by: Coverity CIDs: 1031024, 1305463, 1305494, 1305545 Sponsored by: EMC / Isilon Storage Division 2016-04-19T18:27:28Z Sean Bruno sbruno@FreeBSD.org 2016-04-19T18:27:28Z urn:sha1:f4a18258b0fb0d5f14f6e801854a042d6d552048 anything janky from a user. (cturt) aac(4): landergriffith+freebsdbugzilla@gmail.com pointed out that aacraid(4) had the same issue and handling of pointers, so let's change that too. PR: 206573 Submitted by: cturt@hardenedbsd.org Obtained from: HardenedBSD MFC after: 1 week