From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr2-f35.google.com (mail-wr2-f35.google.com [74.125.225.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E23D318D62A for ; Sun, 27 Sep 2026 06:54:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.99 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790492043; cv=none; b=PwV5YFXoOsYYmSLC31SgLl04+J0e5Jp5kgHVO5kZq5KBDtZRPkblBRc8GMrF9/n87OMgM4zwh3YNZ6OfUoMEPJT4diAyq7d0f6xq4w7ULNTL0FWhBir6FgGBn+97KKHlzdBdgodyTg3NZF3lLeSS0Ve/0bEs/7wGZ9rYo7hL+Yw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790492043; c=relaxed/simple; bh=Rp2X+dx5hQ3lt91Pr5vYcPaasxyyoToGNSTmo5cX7rE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PW+XP5ObK7pC57keX4aecBD+6WyRofU+peVMZkgINQi9OJexAA65vm2w1FygQ2bak81sMuaLud4JZ1AZI/q09P6lg/FzCiJIZI6Ix629q8puu20Rs8aqh7E4InVf8QedowxTfqYwDKA6w/G7nE7vs0oyvZ4o34437TYaZSOQVxs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GVmgCx8I; arc=none smtp.client-ip=74.125.225.99 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GVmgCx8I" Received: by mail-wr2-f35.google.com with SMTP id ffacd0b85a97d-4885d4825adso1189367f8f.0 for ; Sat, 26 Sep 2026 23:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790492040; x=1791096840; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=blA64iov7PIlD+oGU3ZepcahACLOoCoJ8JGCVHSsjCo=; b=GVmgCx8IWI7BJwAGDmQqubdboZkfj9rKj+kWI/YizjieVCyI5F5r/LcTUzaBK8LZuv +Jkv0NEwqONlns2PLh9jel/dshFd7vQ3RpakjyBu3MoUQRlVB+nr+sC+uMspPrjWWKkW uV5T6rwrrco27Ro2bnNZsHhwFawMMdF5Umg5uNAwvO3hGeLH4cex/Im5CqxwTXwYjgyc uiJgyeZeqfUo0oJe5XNNpUBWoKwR/48ydQHVoUNCCoZmg5hJ9dI74lBlIa74TNmtAe4W kkVzpoiX9s39fxRLBfFgor7wv7C7CNutbf3mEqzOWYX1GomXigv0TmSTPlCT64V4Q/DA iTHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790492040; x=1791096840; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=blA64iov7PIlD+oGU3ZepcahACLOoCoJ8JGCVHSsjCo=; b=IQkBRM9SQeOQI299pCCRCCJ5EsCDMSkOj9YLhXyD6KbRExi0gTy0KnKrb73OnOQ5Hf Dy5JdoRgn2ymWJN6AC4k4VNlXadjMNllp53dBRhjEn1Qo/Y1olAzOCRl98A2BlotyR4r pQZd1ReQPquIyyjqMvQcmimbbH2NAacA42F8+fNoFRxP873yiiLqmK7gfM7M38O7BV/o J7/Oz7h5hHa++mJ8ophy/uzaDdqFMI3YZ8bREY6tE9EnQOLU0FQuRiIsW7hrHPiUHPM8 ty/Fqcv/7bQTabPDWm37D9jxGWsTJTcPb/1AlPXajeGPZpGpTsflORGoIaSk0oH3pa4l 6RZQ== X-Forwarded-Encrypted: i=1; AKwUvBxo56/EAWYfxM12IzGlIK5hIyf6+R1CqICCzg+LGrWI3DmHA7P9Rg43fYYuW2370xWXPBnmAcs=@vger.kernel.org X-Gm-Message-State: AFq9FYJf1W15c8hRQVDQssx7S/JmNRFvW3Z9ahT6FbImOmf9XFqKf/Tu Vheg1SBFfD64jgz4+qp+6UNpx3QwXZY+kC7N9D5F6rtJ/gwfk1GZZiDM X-Gm-Gg: AYBFou1pH4HDh1dIZGwMZiBHx98Byhou8hsTCeaE1CimFpR6Zu61FPc1oWCBN3X1OP+ 7QMAer0doOb8BV20UUsmVfBynvj9IU65L3ZwLdrXTpDP2vIC8ATM2bQtNsTGLTbvupo2Zk+rnjy 8TMfO/uHV2nU9fWpp6am7hIBl2Cw+F7zuRZXYLhMKy9FXalYGlIJ/Yoo2RAiJHF0mwfFt2mYMU2 NCwsXbJz2/5F0Th/9AJy3M2QY9C5L9SIutFjJ33bE/7bqf8BEpuinZlGMjR5pFzhQOHY3Ye3HS1 K/GUKYU8Eo04caqE7QkyMVIl5RH3ssJ2FOXqDSU3uepit+tPNqwBOzeRoQOrNwC5HI5gJnnqEGQ rWc4nuTFRDqIaY8IHfwUrsLsvVc+wPeAWEd3VuvN5Vr6WMiK+V5CodK3OCdPK+/8t7gjcXkGfJa Qpf+xEf9SYvrTFyy7ikaHwENCEGyp5i2TcMlbNT4DT4Dd+1JPzsSqXVxgWLR8d94tvyb/7jITZX HMKi7cijzy5Obd/cUsAwCVrbH2IcP2T16ybFRGtXi+RTQ== X-Received: by 2002:a05:6000:2504:b0:487:1256:ab80 with SMTP id ffacd0b85a97d-48871878daemr18432269f8f.57.1790492040099; Sat, 26 Sep 2026 23:54:00 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4887a349a0esm26432209f8f.10.2026.09.26.23.53.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Sep 2026 23:53:59 -0700 (PDT) Date: Sun, 27 Sep 2026 07:53:58 +0100 From: David Laight To: Stanislav Fomichev Cc: Breno Leitao , David Ahern , Ido Schimmel , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , John Fastabend , Stanislav Fomichev , Shuah Khan , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH net-next 1/6] ipv6: reject a negative optlen in do_ipv6_getsockopt() Message-ID: <20260927075358.129e5f65@pumpkin> In-Reply-To: References: <20260925-sockopt_expand_out_v2-v1-0-c3ef2e3bb5c0@debian.org> <20260925-sockopt_expand_out_v2-v1-1-c3ef2e3bb5c0@debian.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 25 Sep 2026 12:02:22 -0700 Stanislav Fomichev wrote: > On 09/25, Breno Leitao wrote: > > IPv4's do_ip_getsockopt() rejects a negative optlen right after reading > > it. do_ipv6_getsockopt() never has, and nothing downstream treats it as > > an error either: len is an int, but every consumer compares it unsigned, > > so -1 behaves as a huge value and each site clamps to its own reply > > size. > > > > len = min_t(unsigned int, sizeof(int), len); > > > > So getsockopt(fd, SOL_IPV6, IPV6_TCLASS, buf, &len) with len set to -1 > > answers 4 bytes and reports 4, rather than failing. > > > > This is a bug ready to bite us in the near future, let's get this fixed. > > > > I've found this because testing the rest of the patch was returning > > inconsistency when optlen = -1. > > If I can do getsockopt with len=-1 today and get 4 bytes back, isn't > that a uapi and we are gonna break someone? > Treating negative values as 4 goes way back into the pre-historic annals, And I agree that there could be code out there that fails to set a value so passes 'dirty stack' and it always works because it never passed 0..3. I suspect all the per-protocol code ought to be passed an unsigned 'len' (and return back a possibly modified value for the wrapper code to give to the user). Then you have somewhere: /* Historic bug compatibility */ ulen = len >= 0 ? len : 4; David