Kimdir01

The GUIX JPEG software decoder enforces no ordering on JPEG markers. A file that places a second `SOF0` frame header after `SOS` re-runs the frame header parser after the output buffer has already been allocated and its geometry latched. The decoder returns `GX SUCCESS` and publishes a `GX PIXELMAP` whose reported dimensions and `data size` exceed the allocation behind it. Any consumer that trusts the returned structure reads out of bounds, including GUIX's own display drivers, reached through the ordinary draw path. Reproduces in the shipped default configuration; `GX SOFTWARE DECODER SUPPORT` is enabled by default.

The PNG chunk reader has no notion of chunk ordering. It records whether an IDAT has been seen and whether a tRNS has already supplied transparency, but nothing prevents an IHDR being read a second time. A PNG carries exactly one IHDR and it is the first chunk. A file that places a second one after IDAT rewrites the image width, height, bit depth and pixel depth *after* the decoded-data buffer has already been allocated and filled from the original values. The pass that reverses the PNG row filters then derives its own extent from the new dimensions and walks the old allocation, moving image bytes past the end of it. The buffer is allocated by GUIX rather than supplied by the caller, so the application has no way to size it defensively. The decoder is compiled in by default.

` gx binres pixelmap table load()` in the GUIX binary resource (theme) loader indexes the pixelmap table with a value read verbatim from the resource file and never bounds it against the table size. A crafted theme drives a write of up to roughly 256 KB past the end of the table. The overflowed buffer is allocated by GUIX itself, through ` gx system memory allocator`, rather than supplied by the caller, so the loader corrupts its own arena. The public API `gx binres theme load()` takes no size parameter, so no amount of caller diligence prevents this. Reproduces in the shipped default configuration; `GX BINARY RESOURCE SUPPORT` is enabled by default.

The GUIX software JPEG decoder reads four kinds of marker segment without checking that each is long enough to hold what it reads. A truncated segment is therefore read past the end of the caller's image buffer. Separately, a zero chroma sampling factor makes the block decode loop non-terminating. Both reproduce in the default configuration, in which `GX SOFTWARE DECODER SUPPORT` is enabled.

**اسم البرنامج المصاب والإصدارات المتأثرة** GUIX (الإصدارات المتأثرة غير محددة) **الوصف** يقوم محمل الموارد الثنائية (المظهر) بتحديد حجم الساحة الخاصة به وتعبئتها في مرحلتين منفصلتين باستخدام حسابات مؤشر مستقلة. يؤدي عدم التحقق من `gx page header data size` مقابل بيانات الغليف الفعلية إلى إمكانية قراءة المرحلتين لرؤوس صفحات مختلفة لنفس صفحة الخط. ينتج عن ذلك حجز ذاكرة أقل مما تكتبه مرحلة التحميل، مما يتسبب في كتابة محتوى من الملف بعد نهاية الساحة. يتم تخصيص المخزن المؤقت الذي حدث به التجاوز عبر ` gx system memory allocator` ، ولا تقبل واجهة برمجة التطبيقات العامة `gx binres theme load()` معامل حجم لمنع ذلك. تحدث هذه المشكلة في التكوين الافتراضي حيث يتم تمكين `GX BINARY RESOURCE SUPPORT`. **التوصيات** في الوقت الحالي، لا توجد معلومات حول إصدار أحدث يحتوي على إصلاح لهذه الثغرة.