From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: Alexander Egorenkov <egorenar@linux.ibm.com>, oberpar@linux.ibm.com
Cc: gor@linux.ibm.com, hca@linux.ibm.com, agordeev@linux.ibm.com,
linux390-list@tuxmaker.boeblingen.de.ibm.com,
linux-s390@vger.kernel.org
Subject: Re: [PATCH v7 2/5] s390/sclp: Introduce macro sclp_gds_for_each()
Date: Wed, 23 Sep 2026 12:57:25 +0200 [thread overview]
Message-ID: <468a1b65-0701-468e-a9e6-de9d63493f88@linux.ibm.com> (raw)
In-Reply-To: <20260923074006.3962077-3-egorenar@linux.ibm.com>
Am 23.09.26 um 09:40 schrieb Alexander Egorenkov:
> sclp_find_gds_{sub}vector() does not deal well with malformed event buffers
> consisting of GDS {sub}vectors. This can result in an infinite loop or
> an out-of-bounds memory read. Therefore, abort with NULL if
> * the next GDS header would exceed the given end boundary
> * the length in a GDS header contains an invalid value.
> A valid length value in a GDS header should be at least as large
> as the size of the corresponding GDS header (2 or 4 bytes)
> but also not lead to exceeding the given end boundary.
>
> Use the new macro in sclp_find_gds_{sub}vector() to iterate over entries
> of a GDS {sub}vector in a safe manner bailing out on the first invalid
> entry.
>
> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
> Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
> Fixes: 30c2df51173e ("[S390] sclp: event buffer dissection")
> ---
> drivers/s390/char/sclp.h | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/s390/char/sclp.h b/drivers/s390/char/sclp.h
> index b31a680e0871..a006d7abfdf3 100644
> --- a/drivers/s390/char/sclp.h
> +++ b/drivers/s390/char/sclp.h
> @@ -360,25 +360,33 @@ sclp_ascebc_str(char *str, int nr)
> (machine_is_vm()) ? ASCEBC(str, nr) : ASCEBC_500(str, nr);
> }
>
> -static inline struct gds_vector *
> -sclp_find_gds_vector(void *start, void *end, u16 id)
> +/* Loop over all GDS {sub}vectors in a safe manner. */
> +#define sclp_gds_for_each(v, n, start, end) \
> + for ((n) = (void*)(end) - (void*)(start), (v) = (typeof(v))(start); \
> + (n) >= sizeof(*(v)) && (v)->length >= sizeof(*(v)) && (v)->length <= (n); \
> + (n) -= (v)->length, (v) = (void*)(v) + (v)->length)
void * instead of void* for checkpatch
> +
> +static inline struct gds_vector *sclp_find_gds_vector(void *start,
> + void *end, u16 id)
> {
> struct gds_vector *v;
> -
> - for (v = start; (void *) v < end; v = (void *) v + v->length)
> + int n;
add a blank line here and below? checkpatch complains. Same for the next patch.
> + sclp_gds_for_each(v, n, start, end) {
> if (v->gds_id == id)
> return v;
> + }
> return NULL;
> }
>
> -static inline struct gds_subvector *
> -sclp_find_gds_subvector(void *start, void *end, u8 key)
> +static inline struct gds_subvector *sclp_find_gds_subvector(void *start,
> + void *end, u8 key)
> {
> struct gds_subvector *sv;
> -
> - for (sv = start; (void *) sv < end; sv = (void *) sv + sv->length)
> + int n;
> + sclp_gds_for_each(sv, n, start, end) {
> if (sv->key == key)
> return sv;
> + }
> return NULL;
> }
>
next prev parent reply other threads:[~2026-09-23 10:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 7:40 [PATCH v7 0/5] s390/sclp: Misc fixes Alexander Egorenkov
2026-09-23 7:40 ` [PATCH v7 1/5] s390/sclp: Make parsing of received event buffers more robust Alexander Egorenkov
2026-09-23 7:52 ` sashiko-bot
2026-09-23 7:40 ` [PATCH v7 2/5] s390/sclp: Introduce macro sclp_gds_for_each() Alexander Egorenkov
2026-09-23 7:52 ` sashiko-bot
2026-09-23 10:57 ` Christian Borntraeger [this message]
2026-09-23 7:40 ` [PATCH v7 3/5] s390/sclp_tty: Make use of sclp_gds_for_each() Alexander Egorenkov
2026-09-23 7:52 ` sashiko-bot
2026-09-23 7:40 ` [PATCH v7 4/5] s390/sclp_ocf: Fix computation of length of GDS values Alexander Egorenkov
2026-09-23 7:49 ` sashiko-bot
2026-09-23 7:40 ` [PATCH v7 5/5] s390/sclp: Ensure no callback gets called after sclp_unregister() returns Alexander Egorenkov
2026-09-23 7:51 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=468a1b65-0701-468e-a9e6-de9d63493f88@linux.ibm.com \
--to=borntraeger@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=egorenar@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=linux390-list@tuxmaker.boeblingen.de.ibm.com \
--cc=oberpar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox