From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D3BD1CAA79 for ; Sat, 24 Jan 2026 16:51:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273483; cv=none; b=S5DnXq1yWUnYgY2Km0VaYDwClbUgx4NSK1+0wtIueBXins8Sppls+sgVDPmXRi9ee6nIIkiiyj4fW+4Q2P0rwO1dOgnfZo9Fiz3MDGUOJO/LGWhdyfjADkcbbC/1FHqQHsEUoC++atZGyeqgIyPzAtLq4lm7NEpBjCJDQ4eU+tA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769273483; c=relaxed/simple; bh=rFKmxm3Wp+0q98ygaCBrCQ6u0tQr6uPQEz+F7nuZCno=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ALnHUJq6INpvhqErANTFGN6oBQ7WEviia+15ntR4dg7fHYpTgX/yZiAH12yR997QZkRSkBVd5JE1+jx3WfE10sfbRexiiiiS5YvXY/lGypVrbeZtNhwe8d8OV6WPfXiCl4HUJ05mKG/CsHqOCgUiOSd8+xFOhX5ASfua5gxWpgU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=HeHNH9DI; arc=none smtp.client-ip=209.85.221.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HeHNH9DI" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-43591b55727so2978138f8f.3 for ; Sat, 24 Jan 2026 08:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769273480; x=1769878280; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Hxw/rJFKy3Zi43PPBn0FyNiBOjhYEoSqVsfDen/FFE0=; b=HeHNH9DIDZa9zH1m7phw8pUGzWfbSuCRVHPVB0Vu9KyXI8RbOxk7oLdZNb+DNRj5xa S4E7E4Er8KbjXMe1axXRRdx3z2VjVn1zwWHvzx/0hCEhQ80q3QHeApTlNP2SlquccURf xucY79Fb7XzSOJTof1x03olO/Ol38pINMIZe7KILn+BpVZeCV/ILF15reUTsveOirB69 A+Y99jPkQpVkr+RMfp2+7XBZ5Xyl53X/YNJBpQS1L4M2RBa+MsFJDEW186mkb7Yw9Bv2 DljJulpeld9F1hgzNhQy2ifdMDMzQpe7cLTBskh1UL4Ck2GO08xeUyrMK5BE9DdFP8Qz u11g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769273480; x=1769878280; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Hxw/rJFKy3Zi43PPBn0FyNiBOjhYEoSqVsfDen/FFE0=; b=IKd1D+Edj2ZzBs0T0bvJhi0vdyO0HZSLMeOfd7r2k4M4H+AmnJ3jHCLBto/lsPkRyo 3uzVjpJwJsyK5S8pYVNW885IbvXyQjtV5p0UxORcEbzqUEfP3wVuMpTGyEAFlfNx5Boz hBt63lba+x5ox9LORajNRG8B1SdbmDpGuQIDnvf5x719EmSmdtGvWV27Gj0ahcQQ/72r 2UnBttgihxgdj8Aemx3dwJSKFb1zOPut3HP/EMa89ScSEsCKR8epA7vK7khbZWChgSYH xeEb33w4FBXz09KXAFbo6eK8PPFLof/s3kLvpRHKfT3kulsHK0GztljXzKbwDqTQy2Fy fASA== X-Forwarded-Encrypted: i=1; AJvYcCVh9IhUuchE39t/X+dsTAboD00Yj0YcW2rfsoA6X+WhaHZ2A34BtOEDQC+SaLQnsf2+ghY8vytQuyFZK2Y=@vger.kernel.org X-Gm-Message-State: AOJu0YxM2bKlEFnfgljL586bkDbOAbXWjrLinlT6UFtSVTSE6Bf9Awnq 0OJKX0Us8XegLiyBLjhLrGMGvtnjt89KAnSBQIaNa9Gln/y9EIFZQqtm X-Gm-Gg: AZuq6aLYkDfJn+d1LOG74+iBj6YbR8yjOJeq+NSzgessw8cmzmp2+yXAsaT2YuWsotp iSuk+2ZtI+OAei0Z4UGzhpguXBRWPBRyapkspHbYp5gDR+O1DS+ZlJw5F6Ne2JS3W+/7AFgFZGj YxGKzLkwlcFWH7agdp82kk80JpCvCwia1qocXi21AhxBgTVHKCwc84v60no0gNZ/pwYGiMopE6Y z+JzYswBlN2wEF4b+Puyn/WrlAkjYZSznWxolrFEWdHekPDaTPO9z2APpDvFyUSE7OWKW0oVa8G gXbv1yG3HK8KVDqncn/ZTt0vW7u7kXlC7Gaw/1b/YA66s/b2s8tLEXabylNSfjlpUdHIcr5EVhn v4XLs9w4M0bte/94u0qwXtLCUhqce3OZXLfEtmGJCFCODimSAHscdnDZkXL4/Yu9oR+H8hCkh4p qfV9oq8b9c7oDQ2xolApY/kpRzJEwZwBwn8dbp3mI9uxM= X-Received: by 2002:a05:6000:2886:b0:435:90a7:8db with SMTP id ffacd0b85a97d-435b159cadamr12739865f8f.15.1769273479706; Sat, 24 Jan 2026 08:51:19 -0800 (PST) Received: from osama ([156.223.77.192]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1f73855sm15431440f8f.29.2026.01.24.08.51.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Jan 2026 08:51:19 -0800 (PST) Date: Sat, 24 Jan 2026 17:51:16 +0100 From: Osama Abdelkader To: Thomas Zimmermann Cc: Simona Vetter , Helge Deller , Lee Jones , Murad Masimov , Quanmin Yan , Yongzhen Zhang , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, syzbot+55e03490a0175b8dd81d@syzkaller.appspotmail.com Subject: Re: [PATCH] fbdev: Fix slab-out-of-bounds read in fb_pad_unaligned_buffer Message-ID: References: <20260118134735.11507-1-osama.abdelkader@gmail.com> <7d4b95ff-8a94-4d96-8b75-6153baad9fdf@suse.de> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7d4b95ff-8a94-4d96-8b75-6153baad9fdf@suse.de> On Mon, Jan 19, 2026 at 08:45:08AM +0100, Thomas Zimmermann wrote: > Hi > > Am 18.01.26 um 14:47 schrieb Osama Abdelkader: > > The function fb_pad_unaligned_buffer() was reading idx+1 bytes per row > > from the source buffer, but when mod == 0 (font width is a multiple of > > 8 bits), the source buffer only has idx bytes per row. This caused a > > slab-out-of-bounds read when accessing src[idx] after the inner loop. > > > > Fix this by only reading the extra byte when mod != 0, ensuring we > > never read beyond the source buffer boundaries. > > > > This fixes the KASAN slab-out-of-bounds read reported by syzkaller: > > https://syzkaller.appspot.com/bug?extid=55e03490a0175b8dd81d > > > > Reported-by: syzbot+55e03490a0175b8dd81d@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=55e03490a0175b8dd81d > > Signed-off-by: Osama Abdelkader > > --- > > drivers/video/fbdev/core/fbmem.c | 18 ++++++++++-------- > > 1 file changed, 10 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c > > index eff757ebbed1..a0c4932a6758 100644 > > --- a/drivers/video/fbdev/core/fbmem.c > > +++ b/drivers/video/fbdev/core/fbmem.c > > @@ -113,15 +113,17 @@ void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 idx, u32 height, > > dst[j+1] = tmp; > > src++; > > } > > - tmp = dst[idx]; > > - tmp &= mask; > > - tmp |= *src >> shift_low; > > - dst[idx] = tmp; > > - if (shift_high < mod) { > > - tmp = *src << shift_high; > > - dst[idx+1] = tmp; > > + if (mod) { > > How do we end up here if mod equals 0? When I look at the callers of this > function, cases with (mod == 0) take an entirely different branch. [1] [2] > > Best regards > Thomas > > [1] https://elixir.bootlin.com/linux/v6.18.6/source/drivers/video/fbdev/core/bitblit.c#L208 > [2] https://elixir.bootlin.com/linux/v6.18.6/source/drivers/video/fbdev/core/fbcon_ud.c#L199 > > > + tmp = dst[idx]; > > + tmp &= mask; > > + tmp |= *src >> shift_low; > > + dst[idx] = tmp; > > + if (shift_high < mod) { > > + tmp = *src << shift_high; > > + dst[idx+1] = tmp; > > + } > > + src++; > > } > > - src++; > > dst += d_pitch; > > } > > } > > -- > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com > GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg) > > You’re right that callers should only reach this path when mod != 0. The issue isn’t the mod == 0 case itself, but that the final source byte is read and consumed even when shift_high >= mod, where no bits are actually used. I resent a version that only accesses the extra byte when it contributes data. Best regards, osama