CVE-2026-46263

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix out-of-bounds stream encoder index v3

eng_id can be negative and that stream_enc_regs[] can be indexed out of bounds.

eng_id is used directly as an index into stream_enc_regs[], which has only 5 entries. When eng_id is 5 (ENGINE_ID_DIGF) or negative, this can access memory past the end of the array.

Add a bounds check using ARRAY_SIZE() before using eng_id as an index. The unsigned cast also rejects negative values.

This avoids out-of-bounds access.

Fixes the below smatch error: dcn*_resource.c: stream_encoder_create() may index stream_enc_regs[eng_id] out of bounds (size 5).

drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351_resource.c 1246 static struct stream_encoder *dcn35_stream_encoder_create( 1247 enum engine_id eng_id, 1248 struct dc_context *ctx) 1249 {

...

1255
1256         /* Mapping of VPG, AFMT, DME register blocks to DIO block instance */
1257         if (eng_id <= ENGINE_ID_DIGF) {

ENGINE_ID_DIGF is 5. should <= be <?

Unrelated but, ugh, why is Smatch saying that eng_id can be negative? end_id is type signed long, but there are checks in the caller which prevent it from being negative.

1258                 vpg_inst = eng_id;
1259                 afmt_inst = eng_id;
1260         } else
1261                 return NULL;
1262

...

1281
1282         dcn35_dio_stream_encoder_construct(enc1, ctx, ctx->dc_bios,
1283                                         eng_id, vpg, afmt,

–> 1284 &stream_enc_regs[eng_id], ^^^^^^^^^^^^^^^^^^^^^^^ This stream_enc_regs[] array has 5 elements so we are one element beyond the end of the array.

...

1287         return &enc1->base;
1288 }

v2: use explicit bounds check as suggested by Roman/Dan; avoid unsigned int cast

v3: The compiler already knows how to compare the two values, so the cast (int) is not needed. (Roman)

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
• To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/540.html

References

• https://git.kernel.org/stable/c/263e28add4f4472cfa95150d218955d1945aa413
• https://git.kernel.org/stable/c/29f3824b08a98d41ecbbfd33580630d7607f962e
• https://git.kernel.org/stable/c/abde491143e4e12eecc41337910aace4e8d59603
• https://git.kernel.org/stable/c/ca3808d560ad946ab6d089fd1f5bee04b952ead4