From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sipsolutions.net (s3.sipsolutions.net [168.119.38.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9A4D388E5F for ; Wed, 8 Apr 2026 07:39:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.38.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775633949; cv=none; b=VjVwPAh5LnrBO4vg8QkY9jkghLlTF4/XIlePe/G3Gz1GKpLURUJvv24gb83wHZjmZ3UILuMFCM2Z7HhsIHfBxrr3yJ92HuB9Hm3t+WSrLKBQs3m5LfVDV/k1pQFFZe9sUfA1traDhaRiPKp+4cl3PoqjgVFgO+VWq2OZW3h/r/8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775633949; c=relaxed/simple; bh=0AB4cxMwsXnOmJui4Pfaf7YA6m+b1S+CkWZ6QXpSx8g=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Ao3VkxUDy7BzsaWpxZlBmcQIjBpSFzrI0OOxlhmwPzYY6nRTNGUTtxK4ZBTs4k/YrpdJix3Pldt6Wmv8gSnjXJ9cZIQkRiCA3Z5hCjhUW7McjIgJKaDeAJcwKOLtE1yLfIv2rOOKf4iRZ9PQTUlXeYvGWq2gUZnsiRHS4UAvFG4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sipsolutions.net; spf=pass smtp.mailfrom=sipsolutions.net; dkim=pass (2048-bit key) header.d=sipsolutions.net header.i=@sipsolutions.net header.b=YkUqyDWT; arc=none smtp.client-ip=168.119.38.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sipsolutions.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sipsolutions.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sipsolutions.net header.i=@sipsolutions.net header.b="YkUqyDWT" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=o8+KM1He4y8YFVz0IVPpHaGgsGzxBtpcXzn8bdfNOks=; t=1775633947; x=1776843547; b=YkUqyDWTeK0Plmaz4naQWnLtl4NFbsQ7vjJywyFAM8CWTM6 wKxUBQEjIZ/sJCat/6O6hFoon5sLyvX+LGaygeGGD44ZBftOwiiQJegGaz6BJtp6+f579KA4OApHb +tFIJxnFkddnB4J7UqtmWkTJDtwRThLeI+nPeWF4RAhOYr0v0XnXjUspotUq+MCZ52Za0Iroiv22g hDZH3OTCmJQ8EObhhunQQNX0YrOurHhPW1FVVTX8exc9uVA0iuw+pKyensqFNk6lBGGbixwS8PjnC JDtlHgP3+qVeXYeZZCn1ezohN+DSTH5xwubUjK3zFqmP1j/eNLkNfG44fq0JVexA==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.98.2) (envelope-from ) id 1wANV9-0000000E7Ov-31Ty; Wed, 08 Apr 2026 09:39:04 +0200 Message-ID: Subject: Re: [PATCH] um: reject out-of-range port channel numbers From: Johannes Berg To: Pengpeng Hou , richard@nod.at Cc: anton.ivanov@cambridgegreys.com, linux-um@lists.infradead.org, linux-kernel@vger.kernel.org Date: Wed, 08 Apr 2026 09:39:02 +0200 In-Reply-To: <20260401160315.88534-1-pengpeng@iscas.ac.cn> References: <20260401160315.88534-1-pengpeng@iscas.ac.cn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-malware-bazaar: not-scanned On Thu, 2026-04-02 at 00:03 +0800, Pengpeng Hou wrote: > port_init() parses the port channel number into an int, formats it into > a small fixed string buffer, and later passes it to htons() for bind(). > Out-of-range values can therefore overflow the local device-name buffer > and still get silently truncated at the socket layer. So ... you have a whole bunch of these fixes, but do we really assume that the kernel command-line is somehow attacker controlled for ARCH=3Dum? Maybe I'm not imagining the right things, but I have a hard time seeing anyone run a service of any sort where the command line gets to be user- controlled, and yet the kernel needs to be secure against that user; in a normal ARCH=3Dum scenario the command line is written by the user as something like linux foo=3Dbar mem=3D256M ... and then can happily attach gdb to the process and muck with it any way they want anyway? I'd probably say the code shouldn't have been this way at the start, but I'm also not convinced it's even really worth fixing for anything but the "look my LLM found _something_" creds... johannes