Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Signed-off-by: Juergen Gross <[email protected]>
---
V2:
- drop BUG_ON() (Christophe Leroy, Greg Kroah-Hartmann)
- replace WARN_ONCE() by pr_err_once() (Greg Kroah-Hartmann)
- break out from original series
---
drivers/tty/hvc/hvc_xen.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 92c9a476defc..8f143c09a169 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -86,7 +86,11 @@ static int __write_console(struct xencons_info *xencons,
cons = intf->out_cons;
prod = intf->out_prod;
mb(); /* update queue values before going on */
- BUG_ON((prod - cons) > sizeof(intf->out));
+
+ if ((prod - cons) > sizeof(intf->out)) {
+ pr_err_once("xencons: Illegal ring page indices");
+ return -EINVAL;
+ }
while ((sent < len) && ((prod - cons) < sizeof(intf->out)))
intf->out[MASK_XENCONS_IDX(prod++, intf->out)] = data[sent++];
@@ -114,7 +118,10 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
*/
while (len) {
int sent = __write_console(cons, data, len);
-
+
+ if (sent < 0)
+ return sent;
+
data += sent;
len -= sent;
@@ -138,7 +145,11 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
cons = intf->in_cons;
prod = intf->in_prod;
mb(); /* get pointers before reading ring */
- BUG_ON((prod - cons) > sizeof(intf->in));
+
+ if ((prod - cons) > sizeof(intf->in)) {
+ pr_err_once("xencons: Illegal ring page indices");
+ return -EINVAL;
+ }
while (cons != prod && recv < len)
buf[recv++] = intf->in[MASK_XENCONS_IDX(cons++, intf->in)];
--
2.26.2
On 07.07.2021 11:10, Juergen Gross wrote:
> Xen frontends shouldn't BUG() in case of illegal data received from
> their backends. So replace the BUG_ON()s when reading illegal data from
> the ring page with negative return values.
>
> Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -86,7 +86,11 @@ static int __write_console(struct xencons_info *xencons,
> cons = intf->out_cons;
> prod = intf->out_prod;
> mb(); /* update queue values before going on */
Largely unrelated note: While in general the barriers here may want
switching to virt_*mb(), this particular one looks to be too heavy
anyway: a read barrier is all that's needed here afaict, just like
there's only a write barrier between ring contents and producer
writing in __write_console().
And btw, since I've got puzzled by the linuxppc-dev@ in the recipients
list, I did look up relevant entries in ./MAINTAINERS. Shouldn't the
file be part of "XEN HYPERVISOR INTERFACE"?
Jan
On 07.07.21 11:57, Jan Beulich wrote:
> On 07.07.2021 11:10, Juergen Gross wrote:
>> Xen frontends shouldn't BUG() in case of illegal data received from
>> their backends. So replace the BUG_ON()s when reading illegal data from
>> the ring page with negative return values.
>>
>> Signed-off-by: Juergen Gross <[email protected]>
>
> Reviewed-by: Jan Beulich <[email protected]>
>
>> --- a/drivers/tty/hvc/hvc_xen.c
>> +++ b/drivers/tty/hvc/hvc_xen.c
>> @@ -86,7 +86,11 @@ static int __write_console(struct xencons_info *xencons,
>> cons = intf->out_cons;
>> prod = intf->out_prod;
>> mb(); /* update queue values before going on */
>
> Largely unrelated note: While in general the barriers here may want
> switching to virt_*mb(), this particular one looks to be too heavy
> anyway: a read barrier is all that's needed here afaict, just like
> there's only a write barrier between ring contents and producer
> writing in __write_console().
I agree.
> And btw, since I've got puzzled by the linuxppc-dev@ in the recipients
> list, I did look up relevant entries in ./MAINTAINERS. Shouldn't the
> file be part of "XEN HYPERVISOR INTERFACE"?
I wouldn't mind. Greg, Jiri, what do you think?
Juergen
On 07. 07. 21, 12:40, Juergen Gross wrote:
>> And btw, since I've got puzzled by the linuxppc-dev@ in the recipients
>> list, I did look up relevant entries in ./MAINTAINERS. Shouldn't the
>> file be part of "XEN HYPERVISOR INTERFACE"?
>
> I wouldn't mind. Greg, Jiri, what do you think?
/me concurs.
thanks,
--
js
suse labs