linux-kernel - Re: [PATCH 11/11] [RFC] drm/i915/dp: fix array overflow warning

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Mar 2021 10:05:06 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Arnd Bergmann <arnd@...nel.org>, linux-kernel@...r.kernel.org,
        Martin Sebor <msebor@....gnu.org>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>
Cc:     Arnd Bergmann <arnd@...db.de>, x86@...nel.org,
        Ning Sun <ning.sun@...el.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        Simon Kelley <simon@...kelleys.org.uk>,
        James Smart <james.smart@...adcom.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        Anders Larsen <al@...rsen.net>, Tejun Heo <tj@...nel.org>,
        Serge Hallyn <serge@...lyn.com>,
        Imre Deak <imre.deak@...el.com>,
        linux-arm-kernel@...ts.infradead.org,
        tboot-devel@...ts.sourceforge.net, intel-gfx@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org, ath11k@...ts.infradead.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-scsi@...r.kernel.org, cgroups@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        Manasi Navare <manasi.d.navare@...el.com>,
        Uma Shankar <uma.shankar@...el.com>,
        Ankit Nautiyal <ankit.k.nautiyal@...el.com>,
        Gwan-gyeong Mun <gwan-gyeong.mun@...el.com>,
        Animesh Manna <animesh.manna@...el.com>,
        Sean Paul <seanpaul@...omium.org>
Subject: Re: [PATCH 11/11] [RFC] drm/i915/dp: fix array overflow warning

On Mon, 22 Mar 2021, Arnd Bergmann <arnd@...nel.org> wrote:
> From: Arnd Bergmann <arnd@...db.de>
>
> gcc-11 warns that intel_dp_check_mst_status() has a local array of
> fourteen bytes and passes the last four bytes into a function that
> expects a six-byte array:
>
> drivers/gpu/drm/i915/display/intel_dp.c: In function ‘intel_dp_check_mst_status’:
> drivers/gpu/drm/i915/display/intel_dp.c:4556:22: error: ‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4 [-Werror=stringop-overread]
>  4556 |                     !drm_dp_channel_eq_ok(&esi[10], intel_dp->lane_count)) {
>       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/gpu/drm/i915/display/intel_dp.c:4556:22: note: referencing argument 1 of type ‘const u8 *’ {aka ‘const unsigned char *’}
> In file included from drivers/gpu/drm/i915/display/intel_dp.c:38:
> include/drm/drm_dp_helper.h:1459:6: note: in a call to function ‘drm_dp_channel_eq_ok’
>  1459 | bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
>       |      ^~~~~~~~~~~~~~~~~~~~
>
> Clearly something is wrong here, but I can't quite figure out what.
> Changing the array size to 16 bytes avoids the warning, but is
> probably the wrong solution here.

Ugh. drm_dp_channel_eq_ok() does not actually require more than
DP_LINK_STATUS_SIZE - 2 elements in the link_status. It's some other
related functions that do, and in most cases it's convenient to read all
those DP_LINK_STATUS_SIZE bytes.

However, here the case is slightly different for DP MST, and the change
causes reserved DPCD addresses to be read. Not sure it matters, but
really I think the problem is what drm_dp_channel_eq_ok() advertizes.

I also don't like the array notation with sizes in function parameters
in general, because I think it's misleading. Would gcc-11 warn if a
function actually accesses the memory out of bounds of the size?

Anyway. I don't think we're going to get rid of the array notation
anytime soon, if ever, no matter how much I dislike it, so I think the
right fix would be to at least state the correct required size in
drm_dp_channel_eq_ok().


BR,
Jani.


>
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 8c12d5375607..830e2515f119 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -65,7 +65,7 @@
>  #include "intel_vdsc.h"
>  #include "intel_vrr.h"
>  
> -#define DP_DPRX_ESI_LEN 14
> +#define DP_DPRX_ESI_LEN 16
>  
>  /* DP DSC throughput values used for slice count calculations KPixels/s */
>  #define DP_DSC_PEAK_PIXEL_RATE			2720000

-- 
Jani Nikula, Intel Open Source Graphics Center