From owner-freebsd-arch@FreeBSD.ORG Fri Apr 3 07:39:10 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B32A3A8 for ; Fri, 3 Apr 2015 07:39:10 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E04F0F74 for ; Fri, 3 Apr 2015 07:39:09 +0000 (UTC) Received: from BLUPR0501MB1060.namprd05.prod.outlook.com (25.160.36.150) by DM2PR0501MB1551.namprd05.prod.outlook.com (25.160.133.141) with Microsoft SMTP Server (TLS) id 15.1.125.19; Fri, 3 Apr 2015 07:39:01 +0000 Received: from BLUPR0501MB1060.namprd05.prod.outlook.com ([25.160.36.150]) by BLUPR0501MB1060.namprd05.prod.outlook.com ([25.160.36.150]) with mapi id 15.01.0125.002; Fri, 3 Apr 2015 07:39:00 +0000 From: Anuranjan Shukla To: "arch@FreeBSD.org" Subject: RFC: chgsbsize doesn't handle -ve sbsize correctly Thread-Topic: chgsbsize doesn't handle -ve sbsize correctly Thread-Index: AQHQbeE/f9SgtMJNR02J2FpJ+QyWpg== Date: Fri, 3 Apr 2015 07:38:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1551; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(122556002)(92566002)(86362001)(2501003)(40100003)(50986999)(54356999)(106116001)(99286002)(36756003)(110136001)(450100001)(102836002)(46102003)(77156002)(2900100001)(62966003)(2351001)(87936001)(66066001)(83506001)(2656002)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1551; H:BLUPR0501MB1060.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR0501MB1551; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1551; x-forefront-prvs: 05352A48BE Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2015 07:38:59.7141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1551 Cc: Simon Gerraty X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 07:39:10 -0000 Hi, In struct uidinfo{}, ui_sbsize member is an int. In a system with large number of sockets owned by a user it's possible for ui_sbsize to roll over to a negative value. When that happens, further calls to _increase_ sbsize don't detect this condition as they should per design. But when the sockets start shutting down this condition would be detected and you'll see the console prints ("negative sbsize for uid =3D") happen. As a worst case the console being flooded with these prints can create a DoS scenario (specially on single CPU systems). Regardless of the end result, the code itself needs to be fixed for correctness. There are two things to note: - Int doesn't seem to be the correct type for ui_sbsize. Should be a u_int atleast. - Since there's no real prevention of the overflow as it happens, the warning print isn't helpful and should be a DEBUG level log at best. If we change ui_sbsize to be a u_int, the negative check itself can go. int chgsbsize(uip, hiwat, to, max) { int diff; diff =3D to - *hiwat; if (diff > 0) { if (atomic_fetchadd_long(&uip->ui_sbsize, (long)diff) + diff > max) { <=3D=3D=3D=3D=3D=3D=3D -ve ui_sbsize goes undetected and we'll pass= the above check=20 atomic_subtract_long(&uip->ui_sbsize, (long)diff); return (0); } } else { atomic_add_long(&uip->ui_sbsize, (long)diff); if (uip->ui_sbsize < 0) printf("negative sbsize for uid =3D %d\n", uip->ui_uid); <=3D=3D=3D=3D Now we'll detect, far too late, that sbsize w= ent -ve