<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/amd/display/dc, branch v6.1.176</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.176</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.176'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-19T11:37:18+00:00</updated>
<entry>
<title>drm/amd/display: Use krealloc_array() in dal_vector_reserve()</title>
<updated>2026-06-19T11:37:18+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2026-05-05T15:52:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b15825deac1acff72638bbc8f05b89ceef8dfb13'/>
<id>urn:sha1:b15825deac1acff72638bbc8f05b89ceef8dfb13</id>
<content type='text'>
commit da48bc4461b8a5ebfb9264c9b191a701d8e99009 upstream.

[Why &amp; How]
dal_vector_reserve() computes the allocation size as
"capacity * vector-&gt;struct_size" using uint32_t arithmetic, which can
silently wrap to a small value on overflow. This would cause krealloc to
return a smaller buffer than expected, leading to heap overflows on
subsequent vector appends.

Replace krealloc() with krealloc_array() which performs an internal
overflow check and returns NULL on wrap, preventing the issue.

Fixes: 2004f45ef83f ("drm/amd/display: Use kernel alloc/free")
Assisted-by: Copilot:claude-opus-4.6
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Ray Wu &lt;ray.wu@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Clamp VBIOS HDMI retimer register count to array size</title>
<updated>2026-06-19T11:37:17+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2026-05-04T19:51:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5f8b39452fb16f507c9e4d8b4a83ce27e893307c'/>
<id>urn:sha1:5f8b39452fb16f507c9e4d8b4a83ce27e893307c</id>
<content type='text'>
commit fb0707ce00eef4e2d60c3020e1c0432739703e4a upstream.

[Why &amp; How]
The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and
Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C
register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9]
and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated
before use, so a malformed VBIOS can specify values up to 255, causing an
out-of-bounds heap write during driver probe.

Clamp each register count to the destination array size using min_t()
before the copy loops, in both get_integrated_info_v11() and
get_integrated_info_v2_1().

Assisted-by: GitHub Copilot:claude-opus-4.6
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Ray Wu &lt;ray.wu@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Reject gpio_bitshift &gt;= 32 in bios_parser_get_gpio_pin_info()</title>
<updated>2026-06-19T11:37:14+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2026-05-05T15:50:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc555e1f3160de0da04f03b36063920d556122ae'/>
<id>urn:sha1:bc555e1f3160de0da04f03b36063920d556122ae</id>
<content type='text'>
commit 49c3da65961fe9857c831d47fa1989084e87514a upstream.

[Why &amp; How]
gpio_bitshift is a uint8_t read directly from the VBIOS GPIO pin table.
If the value is &gt;= 32, the expression "1 &lt;&lt; gpio_bitshift" triggers
undefined behaviour in C (shift count exceeds type width). On x86 the
shift is silently masked to 5 bits, producing an incorrect GPIO mask
that may cause wrong MMIO register bits to be toggled.

Validate gpio_bitshift before use and return BP_RESULT_BADBIOSTABLE for
out-of-range values.

Fixes: ae79c310b1a6 ("drm/amd/display: Add DCE12 bios parser support")
Assisted-by: Copilot:claude-opus-4.6
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Ray Wu &lt;ray.wu@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit eadf438ab8d370b9d19acee9359918c85afeb80d)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async</title>
<updated>2026-06-01T15:39:37+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2026-05-07T20:26:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=16a5fa57565afb6bf37e18129921c270c93d8e2b'/>
<id>urn:sha1:16a5fa57565afb6bf37e18129921c270c93d8e2b</id>
<content type='text'>
commit 6c92f6d9600efa3ef0d9e560a2b52776d9803c29 upstream.

[Why&amp;How]
dc_process_dmub_aux_transfer_async() copies payload-&gt;length bytes into a
16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which
is a no-op in release builds. If a caller ever passes length &gt; 16 this
results in a stack buffer overflow via memcpy.

Additionally, link_index is used to dereference dc-&gt;links[] without
bounds checking against dc-&gt;link_count, risking an out-of-bounds access.

Replace the ASSERT with a hard runtime check that returns false when
payload-&gt;length exceeds the destination buffer size, and add a bounds
check for link_index before it is used.

Assisted-by: GitHub Copilot:Claude claude-4-opus
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Ivan Lipski &lt;ivan.lipski@amd.com&gt;
Tested-by: Dan Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Validate GPIO pin LUT table size before iterating</title>
<updated>2026-06-01T15:39:37+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2026-05-04T20:14:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9900f6954be779011e7c2cd42addd87baf028bc5'/>
<id>urn:sha1:9900f6954be779011e7c2cd42addd87baf028bc5</id>
<content type='text'>
commit 86d2b20644b11d21fe52c596e6e922b4590a3e3f upstream.

[Why&amp;How]
The GPIO pin table parsers in get_gpio_i2c_info() and
bios_parser_get_gpio_pin_info() derive an element count from the VBIOS
table_header.structuresize field, then iterate over gpio_pin[] entries.
However, GET_IMAGE() only validates that the table header itself fits
within the BIOS image. If the VBIOS reports a structuresize larger than
the actual mapped data, the loop reads past the end of the BIOS image,
causing an out-of-bounds read.

Fix this by calling bios_get_image() to validate that the full claimed
structuresize is accessible within the BIOS image before entering the
loop in both functions.

Assisted-by: GitHub Copilot:claude-opus-4-6
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Ivan Lipski &lt;ivan.lipski@amd.com&gt;
Tested-by: Dan Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix integer overflow in bios_get_image()</title>
<updated>2026-06-01T15:39:37+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2026-05-04T15:14:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ca8510a132db4e547b96c0cf28e77f55be1041f3'/>
<id>urn:sha1:ca8510a132db4e547b96c0cf28e77f55be1041f3</id>
<content type='text'>
commit cd86529ec61474a38c3837fb7823790a7c3f8cce upstream.

[Why&amp;How]
The bounds check in bios_get_image() computes 'offset + size' using
unsigned 32-bit arithmetic before comparing against bios_size. If a
VBIOS image contains a near-UINT32_MAX offset the addition wraps to a
small value, the comparison passes, and the function returns a wild
pointer past the VBIOS mapping.

Additionally, the comparison uses '&lt;' (strict), which incorrectly
rejects the valid exact-fit case where offset + size == bios_size.

Fix both issues by restructuring the check to avoid the addition
entirely: first reject if offset alone exceeds bios_size, then check
size against the remaining space (bios_size - offset). This eliminates
the overflow and correctly permits exact-fit accesses.

Assisted-by: GitHub Copilot:claude-opus-4.6
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Ivan Lipski &lt;ivan.lipski@amd.com&gt;
Tested-by: Dan Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit d40fb392af659c4a02b560319f226842f6ec1a95)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Read EDID from VBIOS embedded panel info</title>
<updated>2026-06-01T15:39:30+00:00</updated>
<author>
<name>Timur Kristóf</name>
<email>timur.kristof@gmail.com</email>
</author>
<published>2026-04-28T11:40:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fcc64df4b213a740d8d9b9a9e226e90e34e1be3c'/>
<id>urn:sha1:fcc64df4b213a740d8d9b9a9e226e90e34e1be3c</id>
<content type='text'>
[ Upstream commit 9ea16f64189bf7b6ba50fc7f0325b3c1f836d105 ]

Some board manufacturers hardcode the EDID for the embedded
panel in the VBIOS. This EDID should be used when the panel
doesn't have a DDC.

For reference, see the legacy non-DC display code:
amdgpu_atombios_encoder_get_lcd_info()

This is necessary to support embedded connectors without DDC.

Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192
Signed-off-by: Timur Kristóf &lt;timur.kristof@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit eb105e63b474c11ef6a84a1c6b18100d851ff364)
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Allow DCE link encoder without AUX registers</title>
<updated>2026-06-01T15:39:29+00:00</updated>
<author>
<name>Timur Kristóf</name>
<email>timur.kristof@gmail.com</email>
</author>
<published>2026-04-28T11:40:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0a48fb8cee16b2dc46ffd957f85ad4a713a6bfad'/>
<id>urn:sha1:0a48fb8cee16b2dc46ffd957f85ad4a713a6bfad</id>
<content type='text'>
[ Upstream commit ac27e3f99035f132f23bc0409d0e57f11f054c70 ]

Allow constructing the DCE link encoder without DDC,
which means the AUX registers array will be NULL.

This is necessary to support embedded connectors without DDC.

Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192
Signed-off-by: Timur Kristóf &lt;timur.kristof@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 87f30b101af62590faf6020d106da07efdda199b)
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Add pixel_clock to amd_pp_display_configuration</title>
<updated>2026-03-25T10:03:24+00:00</updated>
<author>
<name>Timur Kristóf</name>
<email>timur.kristof@gmail.com</email>
</author>
<published>2026-03-21T05:44:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e6fd32277e697448c878daf549e4743d823705b7'/>
<id>urn:sha1:e6fd32277e697448c878daf549e4743d823705b7</id>
<content type='text'>
[ Upstream commit b515dcb0dc4e85d8254f5459cfb32fce88dacbfb ]

This commit adds the pixel_clock field to the display config
struct so that power management (DPM) can use it.

We currently don't have a proper bandwidth calculation on old
GPUs with DCE 6-10 because dce_calcs only supports DCE 11+.
So the power management (DPM) on these GPUs may need to make
ad-hoc decisions for display based on the pixel clock.

Also rename sym_clock to pixel_clock in dm_pp_single_disp_config
to avoid confusion with other code where the sym_clock refers to
the DisplayPort symbol clock.

Signed-off-by: Timur Kristóf &lt;timur.kristof@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Rosen Penev &lt;rosenp@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Use GFP_ATOMIC in dc_create_stream_for_sink</title>
<updated>2026-03-25T10:03:14+00:00</updated>
<author>
<name>Natalie Vock</name>
<email>natalie.vock@gmx.de</email>
</author>
<published>2026-03-09T14:30:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3cfe24288efc2ca383a99e85f6bbb8716ed9a13b'/>
<id>urn:sha1:3cfe24288efc2ca383a99e85f6bbb8716ed9a13b</id>
<content type='text'>
[ Upstream commit 28dfe4317541e57fe52f9a290394cd29c348228b ]

This can be called while preemption is disabled, for example by
dcn32_internal_validate_bw which is called with the FPU active.

Fixes "BUG: scheduling while atomic" messages I encounter on my Navi31
machine.

Signed-off-by: Natalie Vock &lt;natalie.vock@gmx.de&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit b42dae2ebc5c84a68de63ec4ffdfec49362d53f1)
Cc: stable@vger.kernel.org
[ Context ]
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
