From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from www.kot-begemot.co.uk (ns1.kot-begemot.co.uk [217.160.28.25]) (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 7E19535CB60 for ; Wed, 8 Apr 2026 08:31:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.160.28.25 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775637109; cv=none; b=DrCFMV8iRpRtKLoBNmqw3iyNg9EeH7xIIWr3wzMMi2T0iHTw1/JBrdVhGCsLWORUU591GZM6BBvTsJjbENT7SlGz0qaxZsamUqTAwpDl7jHtSNTmo5E2Njvb1iAiUAY7ZW6pF3jQZf03QdY7h8Ge98gIzZJYYAECcO414ijwrjY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775637109; c=relaxed/simple; bh=ovoFbcKF6IDaVYwme69lOLD9DXgWV2XNAwomYa+cg44=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=V2h8mmlrKmeg+gRt9BkBIC4fFiVXLwoCsbsGKYiiJui/bd2+vzS/8L+HJpgfz1hUNnQdH0FTwUiBZflpmE2c7TuFxryM4OBHCPm/KzmYVxZ99PIWROS1HeALc7VH+n1vTvuVDw+2U5Y9DWCzIVcXP6WDeeBFUeYxBS/ARtMm9tE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=cambridgegreys.com; spf=pass smtp.mailfrom=cambridgegreys.com; arc=none smtp.client-ip=217.160.28.25 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=cambridgegreys.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cambridgegreys.com Received: from [192.168.17.6] (helo=jain.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1wANq5-00EpGh-9C; Wed, 08 Apr 2026 08:00:42 +0000 Received: from [192.168.21.56] by jain.kot-begemot.co.uk with esmtp (Exim 4.98.2) (envelope-from ) id 1wAMkm-0000000CGGZ-3ISF; Wed, 08 Apr 2026 09:00:40 +0100 Message-ID: <39683457-2145-4586-ba0b-e874839ec24f@cambridgegreys.com> Date: Wed, 8 Apr 2026 09:00:38 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] um: reject out-of-range port channel numbers To: Johannes Berg , Pengpeng Hou , richard@nod.at Cc: linux-um@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260401160315.88534-1-pengpeng@iscas.ac.cn> Content-Language: en-US From: Anton Ivanov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Spam-Score: -1.0 X-Clacks-Overhead: GNU Terry Pratchett On 08/04/2026 08:39, Johannes Berg wrote: > 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=um? > > 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=um scenario the command line is written by the user as > something like > > linux foo=bar mem=256M ... > > 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... +1 > > johannes > -- Anton R. Ivanov Cambridgegreys Limited. Registered in England. Company Number 10273661 https://www.cambridgegreys.com/