From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DFA934BA42 for ; Mon, 18 May 2026 17:59:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779127187; cv=none; b=Yqi0DItKFSQhrKeuDV08uj+KGVGG30s21J141DTvRZCQ9TRNQYX8JAWTE3O8MTmpi/O1UHBsCS9pCapKDNq/7Vvmro+9CgIS6aA/Ycsw2HzmdBRImHjITW35ENon1LIx3+KvZNxXMBGmF/HO2sc4o+t9UtgJJ/CR2xrjuDyLsis= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779127187; c=relaxed/simple; bh=56Gx8U1bBkQwGZUb/0kMvViULOM86+lx0qtC08zx5ls=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=TzdvGzbhaCxuP/lONtVx0oP25oLjUf0kKt/Sa5xlYXPU3Cd8nfBMHOeNW0d7JiPOlJ9oqcRV3HTSKMcEbmDAVQCufjhecWkkv5nz7mnDG9MI5/2Xo+UnJ3wy6ZJepW3OKnxHIbTWLsc44+Ma6Z0DxrrlxDiEgeCXJFRF4zGz5g0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LvQPfcjQ; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Ay0KdeJ8; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LvQPfcjQ"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Ay0KdeJ8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779127185; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u8nJotCS5ieH4qI/fVkCf7erQnf4wXUQWNAiQ92BJeI=; b=LvQPfcjQFf0wiJd3R8WpjfsCMjGGQBBsLAJT9jm4vLWnVfmjjMVh0vTssfwRmhfqx+h2nF tbDW9uZzaCc0bkROiR8apZ2ZQncoKD1rQFCnxYtgWijvkVXjEtkVAWKQ4PpNaaoiYf6Sxw UuqZEBLC+loXVBjbVt6rinh7ldvCZpQ= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-440-57k0a7CIMoWSI6knPJVNOA-1; Mon, 18 May 2026 13:59:44 -0400 X-MC-Unique: 57k0a7CIMoWSI6knPJVNOA-1 X-Mimecast-MFC-AGG-ID: 57k0a7CIMoWSI6knPJVNOA_1779127184 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-8ca1eb491d7so74340126d6.0 for ; Mon, 18 May 2026 10:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779127183; x=1779731983; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=u8nJotCS5ieH4qI/fVkCf7erQnf4wXUQWNAiQ92BJeI=; b=Ay0KdeJ8ocihUI8XZuAKDN5cElfvPBNjXJ88LE2lOI6nG7GAqJqufJAUQdYOpX39TP qphL/AVC57an6sdO9+AmoRRjRYFt6eJ3Hcq3pKiBxTPmfnrQjhh5n76q9m/HbvG9J96d U8GWNoL97NG97k3aaQsPGBlqBvuY51RHV4ywa7ExwZDrtMe7trWilakGyADGq9qhMmJo jANdPkq+nPNuKnJcsDD0ZN6lGbLyXO+NAcDYhpqOUiMHyxzZUrTCKNo9jsvg8xgR/+9j TOgr2PW9Emns7Uk6htgktFgOfFu0srO9Usrbkqb6JuJVfKLFCGv+I7qYW58KEGVpzkBt rf7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779127183; x=1779731983; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=u8nJotCS5ieH4qI/fVkCf7erQnf4wXUQWNAiQ92BJeI=; b=XEqOonUjo5P1CLdIBToPyglFC46yfY1HoIuHU/Htq+O8OFkk0hZZw9NwnNThwpSeGv OqLcL/CbcXWKguHXHXkD2rZzwG7d1pc08+cI5CqJFKxqhq1dvmvyt24JwtkvoGDRDB8G M/JH9d17Ii7ktJ+t5Pdqj6drMVgg/g1GfIlYSkc3wLhQCh9gZQcM0IznVNeSxt4kfoBN B4OCv/tdXOAFYhP+8X4TLgZ6snCqUTD2g+HfMOtPQFr8Sok1swIpF9FNsY7kRjnVeblK V/kH5IDx7pOnESAjqP7yc25fA/tQ4oLNli8jjhS1BSEFYYUIi7lglDL17RNb4kAVM8uW 8bRQ== X-Forwarded-Encrypted: i=1; AFNElJ9BrvuVN5N2M+xnu+OLAO0aKDUIOWxG1lXQU6HyUONNe4i3jgeWI0Ao4JMbfCpNeCs07lYmeEKE574AZYc=@vger.kernel.org X-Gm-Message-State: AOJu0YzHgtVLq2tCfQ3H65gIPlpDeG0k+FHwjNucGVNNBYKSd2JFrOQ1 5HouoybNPzy441lKB/Oj27lJ2fq9krbirexwD5p6hrMET/A/Mh9g0s8+biWBfY1yaXtIV5IUfsG UFieidcNM6dpGoA4o+BaGMvyw2tCRNNlNRXs7Wpdy8pcb/jBrDPmt0/bJ9kO0CkELmg== X-Gm-Gg: Acq92OF7AGE9bo/sDjlJRzghkBgzaJE0VLgydDmb9SLbTF6LOKZn0ftVUg5OH9ei1pt ivU1t3CQ/Xll+ZD14xn3oNg4ST+pKfZqjskqlkZ5C2iPHCQUx22yWAk6sQWT/0IrSwoH7hMT4LR 5zdE1+optuSiFOGZDpE8XxpNQNnWhnYJeQ8gl8mVgy2Trt8beXPva6KdKaONphP8oNYQQCrvOqL kqXtYTLhKq1N060sLS9wfJyPdBClRdyX+CZ6SKdbZwkUpduxIP1OFQ8xKo4LY0g7wBTChysZ2VA Y7NPYNe2XlEZrJ+mO5f/FT8O2Qy0lv+pL9U70wL6hAbGXyOXY2/rmiUrb1Bk3dTWSo5ZDX8Xmox U0RBupmBzgzjJ+2X4wA== X-Received: by 2002:a05:6214:5e06:b0:8ca:1f6b:a27d with SMTP id 6a1803df08f44-8ca1f6ba690mr181284956d6.20.1779127183520; Mon, 18 May 2026 10:59:43 -0700 (PDT) X-Received: by 2002:a05:6214:5e06:b0:8ca:1f6b:a27d with SMTP id 6a1803df08f44-8ca1f6ba690mr181284626d6.20.1779127183069; Mon, 18 May 2026 10:59:43 -0700 (PDT) Received: from [192.168.8.4] ([100.0.180.93]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ca3619c7d9sm62373116d6.36.2026.05.18.10.59.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 10:59:42 -0700 (PDT) Message-ID: <04a87b5cebc6aeea103997c453e0487ffee70022.camel@redhat.com> Subject: Re: [PATCH v2] drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers From: lyude@redhat.com To: Ashutosh Desai , dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org, airlied@gmail.com, daniel@ffwll.ch, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, simona@ffwll.ch, linux-kernel@vger.kernel.org Date: Mon, 18 May 2026 13:59:41 -0400 In-Reply-To: <20260510203128.2884846-1-ashutoshdesai993@gmail.com> References: <20260510203128.2884846-1-ashutoshdesai993@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Reviewed-by: Lyude Paul Will push to drm-misc-next in just a moment On Sun, 2026-05-10 at 20:31 +0000, Ashutosh Desai wrote: > Three sideband reply parsers read 16-bit fields as: >=20 > =C2=A0 val =3D (raw->msg[idx] << 8) | (raw->msg[idx+1]); >=20 > and check bounds only after the fact. When idx =3D=3D raw->curlen, > raw->msg[idx+1] reads one byte past the received message data into > the following struct fields (curchunk_len, curchunk_idx, curlen). >=20 > Affected functions: > =C2=A0- drm_dp_sideband_parse_enum_path_resources_ack() > =C2=A0=C2=A0 full_payload_bw_number and avail_payload_bw_number fields > =C2=A0- drm_dp_sideband_parse_allocate_payload_ack() > =C2=A0=C2=A0 allocated_pbn field > =C2=A0- drm_dp_sideband_parse_query_payload_ack() > =C2=A0=C2=A0 allocated_pbn field >=20 > Fix by using a single combined check (idx + 2 > curlen) before each > 2-byte read. Since the check is strictly tighter than idx > curlen, > no separate step is needed. >=20 > Cc: stable@vger.kernel.org > Signed-off-by: Ashutosh Desai > --- > Changes in v2: > - Drop separate idx > curlen check immediately before idx + 2 > > curlen; > =C2=A0 the combined check strictly subsumes it (Lyude Paul) >=20 > =C2=A0drivers/gpu/drm/display/drm_dp_mst_topology.c | 17 ++++------------= - > =C2=A01 file changed, 4 insertions(+), 13 deletions(-) >=20 > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c > b/drivers/gpu/drm/display/drm_dp_mst_topology.c > index 9416a48804c8..6e7896193772 100644 > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c > @@ -925,16 +925,13 @@ static bool > drm_dp_sideband_parse_enum_path_resources_ack(struct drm_dp_sideband > =C2=A0 repmsg->u.path_resources.port_number =3D (raw->msg[idx] >> 4) > & 0xf; > =C2=A0 repmsg->u.path_resources.fec_capable =3D raw->msg[idx] & 0x1; > =C2=A0 idx++; > - if (idx > raw->curlen) > + if (idx + 2 > raw->curlen) > =C2=A0 goto fail_len; > =C2=A0 repmsg->u.path_resources.full_payload_bw_number =3D (raw- > >msg[idx] << 8) | (raw->msg[idx+1]); > =C2=A0 idx +=3D 2; > - if (idx > raw->curlen) > + if (idx + 2 > raw->curlen) > =C2=A0 goto fail_len; > =C2=A0 repmsg->u.path_resources.avail_payload_bw_number =3D (raw- > >msg[idx] << 8) | (raw->msg[idx+1]); > - idx +=3D 2; > - if (idx > raw->curlen) > - goto fail_len; > =C2=A0 return true; > =C2=A0fail_len: > =C2=A0 DRM_DEBUG_KMS("enum resource parse length fail %d %d\n", > idx, raw->curlen); > @@ -952,12 +949,9 @@ static bool > drm_dp_sideband_parse_allocate_payload_ack(struct drm_dp_sideband_ms > =C2=A0 goto fail_len; > =C2=A0 repmsg->u.allocate_payload.vcpi =3D raw->msg[idx]; > =C2=A0 idx++; > - if (idx > raw->curlen) > + if (idx + 2 > raw->curlen) > =C2=A0 goto fail_len; > =C2=A0 repmsg->u.allocate_payload.allocated_pbn =3D (raw->msg[idx] << > 8) | (raw->msg[idx+1]); > - idx +=3D 2; > - if (idx > raw->curlen) > - goto fail_len; > =C2=A0 return true; > =C2=A0fail_len: > =C2=A0 DRM_DEBUG_KMS("allocate payload parse length fail %d %d\n", > idx, raw->curlen); > @@ -971,12 +965,9 @@ static bool > drm_dp_sideband_parse_query_payload_ack(struct drm_dp_sideband_msg_r > =C2=A0 > =C2=A0 repmsg->u.query_payload.port_number =3D (raw->msg[idx] >> 4) & > 0xf; > =C2=A0 idx++; > - if (idx > raw->curlen) > + if (idx + 2 > raw->curlen) > =C2=A0 goto fail_len; > =C2=A0 repmsg->u.query_payload.allocated_pbn =3D (raw->msg[idx] << 8) > | (raw->msg[idx + 1]); > - idx +=3D 2; > - if (idx > raw->curlen) > - goto fail_len; > =C2=A0 return true; > =C2=A0fail_len: > =C2=A0 DRM_DEBUG_KMS("query payload parse length fail %d %d\n", > idx, raw->curlen);