From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 25E54358D3D for ; Tue, 14 Apr 2026 10:02:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776160978; cv=none; b=Lh8jl5NyMlSY5xeOO+/klwBE8ODjLrMb7FHkCy0w2hc3iAi2gjVHQ7GV5S0hUwzREYCwII6mT3nXEQNwsK3kq2/RpvPzzJvDzgwUou2RVgNzXzXbadyxb7giNj1tzr2FvClOWnc6dKMmzNVUh+Bb9D025ZkRaJOFKsiqa36VSnQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776160978; c=relaxed/simple; bh=TMGznutSelPaLevV10rNrfK2Z8Js1xbIKFp3HaQ8RAo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nyIft7Up5aYkUEtc7SGnibz0mjy/SfTAn6noLAKpv+ZTlrjT9tZmh++NCI+TOuVeYB+SO7yWFvb11+FxjtzbhU2bBrpD/rthdbMYmoBeP4nJDs0XSgDBs7140hm1Zg+ERHgFv6qVmaUjsiZCLnl653si2xETaGOW4lYe/sUaRco= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Llr35qQS; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=NsVpk/t+; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Llr35qQS"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="NsVpk/t+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776160976; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=F4rwg9mtlb7HY5lOaSaHKUxubiv+YU0hUCTj5zDJcuQ=; b=Llr35qQSOkxPuOYXftNaYuSBnJuW5ErnH3ZlpT7JvFc/yvzxFuQy5h4UQ4LxCgLwiePsP0 BnDP0bkMaDlJTlC+L/LSbH94Q21uMnij7RkTaR4Q+eOOd63KkEbXcuqAsdyDUVrn6vCuTy vOzRw+fJFRW+Ynxa580yOyFa3OuHopc= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-599-6lEo31oFMrGbeg3gCIpEuQ-1; Tue, 14 Apr 2026 06:02:55 -0400 X-MC-Unique: 6lEo31oFMrGbeg3gCIpEuQ-1 X-Mimecast-MFC-AGG-ID: 6lEo31oFMrGbeg3gCIpEuQ_1776160974 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-488c2cc0cbaso30267135e9.3 for ; Tue, 14 Apr 2026 03:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776160974; x=1776765774; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=F4rwg9mtlb7HY5lOaSaHKUxubiv+YU0hUCTj5zDJcuQ=; b=NsVpk/t+RcvEZiltUlT4eBLAZjXEFErv1FQsT3w1aZ7XI6YmLQSU9vfsVq+K7fEW6W /UESAFTQXbJCAmFkcc4UT6HBTsfb7wv0BGyMMTQBqMoElUt0Z56QhN7FlU9vwOJuaxpq 7R9DnI0Eon7+H/iT2X0q+pBXVd6nOWCGTh0/kre2wl8VLzdNMwHNU//dk1QJask+q7O0 SLire6CyqpDIg+JrlTeMlNb3IM+Aw8fRjC9ASywHdMg4w85QYNoE9sEanXfFtna1Sorp LAbivjJVMkuAM/BV52UUbzeXqP8tggdt7q6oz1i+Fp71SIMDHcIy9Ah7shg3md2KysfM G1Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776160974; x=1776765774; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=F4rwg9mtlb7HY5lOaSaHKUxubiv+YU0hUCTj5zDJcuQ=; b=QOPaU0HdtOweRjNotTchKkWqvp4XZLCuSeTfafZP7jorNAvH98PXFNGisrrr9LUC3p 4+6DLw2e2NqGy9wTfnwEQ3wOW4N8zzsFpIJevv+x1sHbWbxU3GsXd0UrdhYWH8nj2xOC Z6m8S+mnFePN4tL10OCUCDrxTC1MNa0+Y0G+y0IwOaEMXlI/9MfZnSWDhu3xVtQ/JblH DiwxTlTOXpzFzrh18H40kiX8mX4NMbIqFgsxESSEgrKoUk52W2JQPk2FIWwUZkxgms8w bXf2g/ScvbIQN+epWKyGnexewxXjckzEy+adEuiiGB/w/+5pEonlGrOJaMinBtgl/m++ I9zA== X-Gm-Message-State: AOJu0YzifaosbtpjdrAnyQNwACXhEvNF8IqkPXcEVx4Od7Vo3EqfbbcU BYrANw9mSCYsEawmdLF6c7JTnGReiugzi008i5i5UxJxBh42Qp6AOZerXHnVmK3h210AAD5AWvG vaJiga7ScuHrsQN5GT4sdzECyqzOeqfZTUldfK1XYJ7KdB9yAd5dGjgMrnev2JQiLdg== X-Gm-Gg: AeBDieu+dTgcoBsccJVwH4T0n/xTioDMdfou9eej9DRQ3FRi2AkfSZqyFhAuyeON2QL 0PKNTxwwQLsqdXi3b28Tfjn6ahNZlMBmlIiqP8DDdsTkigv5apij61GG0CD6cFz9HyXtZrObN1j rc4BFblYFgWQTSA9t9c8kB0FbyPqaeShgSBVRebgqZGqZdJPflCL4KtiwLS3qd0Lb7FxO5fkrr8 FFgtLn11KAOWIhe3SKI1Swm/+ZhaTuzIAdgXOCLpDn5568BwdsLTz6VihkjdNvj6GdBqS3A4RkI b68SlrUreqjSQg8oZIJgQVwcIcf8j8CHevy4a52GsBgQoniUNlHwZ2hY1HlAzLcNEu+Xvgv16WP Y3x05+2qOQ2qIgxJdd2AX1KAt1ZEEYoJb2RcF6TlA8oSyrprIFYc+mKFQ X-Received: by 2002:a05:600c:64cf:b0:485:b6dd:5066 with SMTP id 5b1f17b1804b1-488d67ce664mr221527455e9.7.1776160973494; Tue, 14 Apr 2026 03:02:53 -0700 (PDT) X-Received: by 2002:a05:600c:64cf:b0:485:b6dd:5066 with SMTP id 5b1f17b1804b1-488d67ce664mr221527035e9.7.1776160973016; Tue, 14 Apr 2026 03:02:53 -0700 (PDT) Received: from [192.168.88.32] ([216.128.11.125]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488d681ea59sm121156575e9.14.2026.04.14.03.02.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Apr 2026 03:02:52 -0700 (PDT) Message-ID: Date: Tue, 14 Apr 2026 12:02:51 +0200 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 net] net: sched: em_text: require NUL-terminated algo name To: Greg Kroah-Hartman , netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Jamal Hadi Salim , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , stable References: <2026041150-task-path-81dd@gregkh> Content-Language: en-US From: Paolo Abeni In-Reply-To: <2026041150-task-path-81dd@gregkh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/11/26 1:10 PM, Greg Kroah-Hartman wrote: > em_text_change() copies the user-supplied tcf_em_text struct from > netlink and passes conf->algo straight to textsearch_prepare(), which > forwards it to lookup_ts_algo() (strcmp) and request_module() (vsnprintf > %s). But the algo[16] field is never validated to be NULL-terminated, > so a fully populated array reads past it into the adjacent > from_offset/to_offset/pattern_len fields and the trailing pattern bytes > during the string operations. > > This type of pattern is properly checked in the string_mt_check() for > xt_string netfilter matching function, but for some reason was not added > here, so fix this up by doing the same exact thing. > > Cc: Jamal Hadi Salim > Cc: Jiri Pirko > Cc: "David S. Miller" > Cc: Eric Dumazet > Cc: Jakub Kicinski > Cc: Paolo Abeni > Cc: Simon Horman > Fixes: d675c989ed2d ("[PKT_SCHED]: Packet classification based on textsearch (ematch)") > Cc: stable > Assisted-by: gregkh_clanker_t1000 > Signed-off-by: Greg Kroah-Hartman > --- > Note, my tools flagged this, so I fixed this up the same way that > string_mt_check() did, but if there is some other way that this should > be resolved, or I got this totally wrong that this isn't an issue, > please let me know, thanks! > > > net/sched/em_text.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/sched/em_text.c b/net/sched/em_text.c > index 343f1aebeec2..24a8aa21971d 100644 > --- a/net/sched/em_text.c > +++ b/net/sched/em_text.c > @@ -58,6 +58,9 @@ static int em_text_change(struct net *net, void *data, int len, > if (len < sizeof(*conf) || len < (sizeof(*conf) + conf->pattern_len)) > return -EINVAL; > > + if (conf->algo[sizeof(conf->algo) - 1] != '\0') > + return -EINVAL; The addressed issue looks real to me, but sashiko found a problem with this fix: --- Is this NUL-termination check too strict and could it introduce an ABI regression? If a userspace application sends a valid, NUL-terminated string that is shorter than 15 characters, but does not explicitly zero-pad the remaining uninitialized bytes in the tcf_em_text struct, this check will fail with -EINVAL. Prior to this patch, the kernel's string operations safely stopped reading at the first \0 byte, correctly processing these shorter strings. Rejecting previously valid structures breaks backward compatibility with existing userspace binaries. Would it be better to check for NUL-termination using memchr() or strnlen() instead? For example, memchr(conf->algo, '\0', sizeof(conf->algo)) == NULL. --- /P