linux-kernel - Re: [PATCH] drm/i915/dp: fix shifting by a negative number of bits

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: <1536789750.2958.17.camel@intel.com>
Date:   Wed, 12 Sep 2018 15:02:30 -0700
From:   Paulo Zanoni <paulo.r.zanoni@...el.com>
To:     "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        David Airlie <airlied@...ux.ie>
Cc:     intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org,
        "Vivi, Rodrigo" <rodrigo.vivi@...el.com>
Subject: Re: [PATCH] drm/i915/dp: fix shifting by a negative number of bits

Em Qua, 2018-09-12 às 09:31 -0500, Gustavo A. R. Silva escreveu:
> Function intel_port_to_tc() returns PORT_TC_NONE on error, which is
> a negative value -1. In case PORT_TC_NONE is returned, there is an
> undefined behavior when shifting by a negative number of bits in
> both DP_PHY_MODE_STATUS_NOT_SAFE and P_PHY_MODE_STATUS_COMPLETED
> macros.
> 
> Fix this by adding sanity checks on intel_port_to_tc return value,
> before
> using macros DP_PHY_MODE_STATUS_NOT_SAFE and
> P_PHY_MODE_STATUS_COMPLETED.

This was just discussed yesterday in a patch by Rodrigo:

https://patchwork.freedesktop.org/patch/246903/

I would personally prefer his version because it avoids passing -1 to
register macros that Coverity doesn't seem to care about, it's a single
check and it prints WARN() instead of DRM_DEBUG_KMS().

Although I do prefer your commit message explanation :).

Perhaps I should reconsider my vote to not merge it. Or we could
actually go and test what happens when intel_port_to_tc() is broken,
fixing all the issues instead of just the ones reported by Coverity.

Anyway, Rodrigo's patch with an improved commit message could receive
my R-B tag now.

> 
> Addresses-Coverity-ID: 1473324 ("Bad bit shift operation")
> Addresses-Coverity-ID: 1473325 ("Bad bit shift operation")
> Fixes: 39d1e234e1e1 ("drm/i915/icl: implement the tc/legacy HPD
> {dis,}connect flows")
> Signed-off-by: Gustavo A. R. Silva <gustavo@...eddedor.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 436c22d..e34b7b1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4811,6 +4811,11 @@ static bool icl_tc_phy_connect(struct
> drm_i915_private *dev_priv,
>  	    dig_port->tc_type != TC_PORT_TYPEC)
>  		return true;
>  
> +	if (tc_port < 0) {
> +		DRM_DEBUG_KMS("Bad TC port %d\n", tc_port);
> +		return false;
> +	}
> +
>  	val = I915_READ(PORT_TX_DFLEXDPPMS);
>  	if (!(val & DP_PHY_MODE_STATUS_COMPLETED(tc_port))) {
>  		DRM_DEBUG_KMS("DP PHY for TC port %d not ready\n",
> tc_port);
> @@ -4857,6 +4862,10 @@ static void icl_tc_phy_disconnect(struct
> drm_i915_private *dev_priv,
>  	    dig_port->tc_type != TC_PORT_TYPEC)
>  		return;
>  
> +	if (tc_port < 0) {
> +		DRM_DEBUG_KMS("Bad TC port %d\n", tc_port);
> +		return;
> +	}
>  	/*
>  	 * This function may be called many times in a row without
> an HPD event
>  	 * in between, so try to avoid the write when we can.