From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 5ED6634CFBA for ; Thu, 30 Jul 2026 12:49:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785415799; cv=none; b=IxnVnVTvGWUrUpoWg258lL3bJDDDhCMft+R1HP1cgG3gsjO9B4rni5Rwe8zHfxD1nHkPzRypxBx+w07u05LknNf+nSbmdAgA66u/4wcd8A0YYjBf/FNM7lZJVbI0egUNeqRwAh0NlV+RLFPf8I4BQuWG3bRs8rFoNdDEHmX2bU4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785415799; c=relaxed/simple; bh=1ulvNbdew7srx8vccwI0cryBIpdbubR713Zc/cqvvjo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QInTLz2ikaSwCsQ6jFGu9Y+tIr2zaSyv0D3NYcfG5iPP+0AkoiFNsqlGSaL/amoDE9fOQhLeoBd24NoVwNZXeW5Kk0LYJnDj1X6Eo+ATcYossK/SXzuANgpwenlVSDjoLcP/qDApdushR98JT9MPBE1UlPhTIk22OZhCXgeT/FA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=gYGnDz6p; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="gYGnDz6p" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 297021F00A3A; Thu, 30 Jul 2026 12:49:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1785415797; bh=BtPYLW9Cx0ug8ANzoHbD/034B79MKCL6z6t2PPxufOE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gYGnDz6plvXmLBWii6ZOLniNKJ8qA5QLrw24bSY4IR6uyfDeagA8yRFTYDxc4xSkB FJm9ylFEFW/cssZ/SyIBazHJ+BgCvLhEqyh3wNqFCRMMCanHrww1f779iQrDQB0+09 2uG9j7JcR0WUxd9ZYeirToEi8ZjvDcIzO4t9Ofv4= Date: Thu, 30 Jul 2026 14:49:43 +0200 From: "gregkh@linuxfoundation.org" To: Siddh Raman Pant Cc: "cve@kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: CVE-2026-63985: ethtool: eeprom: add more safeties to EEPROM Netlink fallback Message-ID: <2026073017-promotion-pacemaker-8384@gregkh> References: <2026071903-CVE-2026-63985-56d0@gregkh> <288bcae3fed67bac04b90922cca0f03d7bbfdfcf.camel@oracle.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <288bcae3fed67bac04b90922cca0f03d7bbfdfcf.camel@oracle.com> On Thu, Jul 30, 2026 at 12:45:14PM +0000, Siddh Raman Pant wrote: > On Sun, 19 Jul 2026 16:57:25 +0200, Greg Kroah-Hartman wrote: > > ethtool: eeprom: add more safeties to EEPROM Netlink fallback > > > > The Netlink fallback path for reading module EEPROM > > (fallback_set_params()) validates that offset < eeprom_len, > > but does not check that offset + length stays within eeprom_len. > > The ioctl equivalent (ethtool_get_any_eeprom() in ioctl.c) has > > always enforced both bounds: > > > > if (eeprom.offset + eeprom.len > total_len) > > return -EINVAL; > > > > This could lead to surprises in both drivers and device FW. > > Add the missing offset + length validation to fallback_set_params(), > > mirroring the ioctl. > > > > Similarly - ethtool core in general, and ethtool_get_any_eeprom() > > in particular tries to zero-init all buffers passed to the drivers > > to avoid any extra work of zeroing things out. eeprom_fallback() > > uses a plain kmalloc(), change it to zalloc. > > > > The Linux kernel CVE team has assigned CVE-2026-63985 to this issue. > > IIUC this is a defensive fix. Does it fix any reported problem for it > to be a CVE? As-is, it seems to fix a vulnerability. Do you think that is not the case, and if so, why? thanks, greg k-h