lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250830174810.GAaLM5WkiFc2BtQ6kW@fat_crate.local>
Date: Sat, 30 Aug 2025 19:48:10 +0200
From: Borislav Petkov <bp@...en8.de>
To: Alex Deucher <alexdeucher@...il.com>
Cc: amd-gfx@...ts.freedesktop.org, Alex Deucher <alexander.deucher@....com>,
	Christian König <christian.koenig@....com>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource
 seems too big for the bo

On Sat, Aug 30, 2025 at 12:30:09PM -0400, Alex Deucher wrote:
> Yes, I agree these should be warn_once().  If you send a patch I'll
> apply it, otherwise, I'll take a look next week. 

See below. I tried to explain the whole situation as good as I could.

> For some background, older GPUs did not support memory protection, so the
> kernel driver validates all of the command submissions (CS) from userspace
> to make sure the commands would not access any memory they shouldn't.  In
> your case it's a vertex buffer object (VBO) which contains vertex data for
> the 3D engine on the GPU.  So newer mesa code is sending a command
> submission with an invalid vbo size.  As such the kernel driver rejects the
> command submission.  This may result in subtle rendering issues as the
> invalid command submission does not get sent to the hardware. 

Very nice, thanks! I've added it to the commit message.

> I would suggest filing a mesa bug report:
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/

Right, I'd love to except that's my main workstation and I don't love
testing/debugging kernels on it. The thing must JustWork(tm).

I'll try to repro on some of my other boxes and report it then.

Thanks Alex!

---
From: "Borislav Petkov (AMD)" <bp@...en8.de>
Date: Sat, 30 Aug 2025 19:24:28 +0200
Subject: [PATCH] drm/radeon/evergreen_cs: Make the VBO size mismatch message a once-type

With newer MESA (version 9.0.2 in Debian), the message

  [54588.405160] evergreen_packet3_check: 32 callbacks suppressed
  [54588.405166] radeon 0000:1d:00.0: vbo resource seems too big for the bo
  [54588.418034] radeon 0000:1d:00.0: vbo resource seems too big for the bo
  [54588.418037] radeon 0000:1d:00.0: vbo resource seems too big for the bo
  ...

floods dmesg and the ratelimiting doesn't help a whole lot. The user
can't really do anything about it so make it a once message.

Some background info from Alex:

"[O]lder GPUs did not support memory protection, so the kernel driver
validates all of the command submissions (CS) from userspace to make
sure the commands would not access any memory they shouldn't.

In your case it's a vertex buffer object (VBO) which contains vertex
data for the 3D engine on the GPU.  So newer mesa code is sending
a command submission with an invalid vbo size.  As such the kernel
driver rejects the command submission.

This may result in subtle rendering issues as the invalid command
submission does not get sent to the hardware.  I would suggest filing
a mesa bug report:

https://gitlab.freedesktop.org/mesa/mesa/-/issues"

So users are encouraged to report this bug if they catch it in their
dmesg.

Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
Link: https://lore.kernel.org/r/20250829171655.GBaLHgh3VOvuM1UfJg@fat_crate.local
---
 drivers/gpu/drm/radeon/evergreen_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c
index a46613283393..6285ff1b1bff 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -2418,7 +2418,7 @@ static int evergreen_packet3_check(struct radeon_cs_parser *p,
 				size = radeon_get_ib_value(p, idx+1+(i*8)+1);
 				if (p->rdev && (size + offset) > radeon_bo_size(reloc->robj)) {
 					/* force size to size of the buffer */
-					dev_warn_ratelimited(p->dev, "vbo resource seems too big for the bo\n");
+					dev_warn_once(p->dev, "vbo resource seems too big for the bo\n");
 					ib[idx+1+(i*8)+1] = radeon_bo_size(reloc->robj) - offset;
 				}
 
-- 
2.51.0



-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ