From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 318583EC836 for ; Mon, 24 Aug 2026 08:59:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787561982; cv=none; b=aeb01dVg1qoSeh/TOMyaGIHnf2J1QT4dFP/7c4O3srRpvS2penTIi3X/tJHA/qbmG8e48JqyubsAaHXq1TS3K6oYiuNqwRHk2V2HAFNyQKVzAL3NZ0wUyf1EUV0a4fFjsM86r4Ty/sjiPJ+F+V6dTYOGFtY33RpvhlR+lVAnWAU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787561982; c=relaxed/simple; bh=xD3ZVhiv3S6/xvTY/hQeH/RBQov8u8bAVX39CY321XY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pToxydaVZRPZZ2sfXWzVoPjB4cCGrFgPTRSwGySla0KEC4nTTfMqGZ/DAMQDjYREhxMmESMDCHBkzBpoFFA7xQJVSGqodMm2rQCeWJBMHRzhk4xP05ltEtd77PG+4r8xKZBuPMYC8c5O7acWgYEUGBN8vrcb/xrl4G3uwReFGwk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Gr8yjHUE; arc=none smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Gr8yjHUE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1787561979; x=1819097979; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=xD3ZVhiv3S6/xvTY/hQeH/RBQov8u8bAVX39CY321XY=; b=Gr8yjHUEZDRQu/n++dtMscs4GW+yAZZxrlwQL+ShWEGUOVbuLc3WVhlo HrgqYSLvtIhTR6Jukhv4iyfhQEGGl8t9yRLQddl/ko65+I4By0hZE0Dh7 R6P5JV/nVLlFvFX06O+lQKcVh5eLSKMSXt8SQCdGYTlTWq8QnY46GXIyW 1cJaMyM17n40wiNnVJIFIkCNFuIJm7E0zJo/ON5sayKyUdBZhs8CZq+5f r2SRs89cJOmjv4E9uojq7zKXO8kMMBNN9kPO06VmkV5uLVCRAkeG2wrs1 hRhVLvp7qPXCOLN2kAEQMojT9OlBDUIMMeeGA6lm7xIyJvGM8Vw40whmP Q==; X-CSE-ConnectionGUID: 3hJ7MP0/TKKhoofqYDD9lQ== X-CSE-MsgGUID: cIxJaZQGQvmJPj8kgIluqQ== X-IronPort-AV: E=McAfee;i="6800,10657,11884"; a="88022797" X-IronPort-AV: E=Sophos;i="6.25,240,1779174000"; d="scan'208";a="88022797" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2026 01:59:36 -0700 X-CSE-ConnectionGUID: Y7/NezxmSk60n3rVoTSsvA== X-CSE-MsgGUID: RFwQHik+TO6IgBDv0RjAJw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,240,1779174000"; d="scan'208";a="268904673" Received: from conormcd-mobl2.ger.corp.intel.com (HELO localhost) ([10.245.244.130]) by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2026 01:59:31 -0700 Date: Mon, 24 Aug 2026 11:59:29 +0300 From: Andy Shevchenko To: Tomasz Unger Cc: Andy Shevchenko , Greg Kroah-Hartman , dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, Dan Carpenter Subject: Re: [PATCH v2] staging: fbtft: prefer snprintf over sprintf in fbtft-core.c Message-ID: References: <20260820-fbtft-v2-final-v2-1-44d107b04634.ref@yahoo.pl> <20260820-fbtft-v2-final-v2-1-44d107b04634@yahoo.pl> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260820-fbtft-v2-final-v2-1-44d107b04634@yahoo.pl> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Thu, Aug 20, 2026 at 06:58:12PM +0200, Tomasz Unger wrote: > Using sprintf has potential for buffer overflows if the formatted sprintf() > string exceeds the destination buffer size. Replace it with > snprintf, passing sizeof() of the fixed-size stack buffers snprintf() > (text1[50] and text2[50]) so the write is always bounded. > > An overflow is impossible here: even the worst case for the > argument types (size_t for text1, three ints for text2) still > fits within 50 bytes. Use snprintf() rather than scnprintf() > since the return value is not used here. Then why the patch is needed at all? Do you have any compiler that warns you about something? ... It looks like you ignored all my comments against v1... -- With Best Regards, Andy Shevchenko