diff options
| author | Jan Beulich <jbeulich@suse.com> | 2024-01-08 09:55:56 +0100 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2024-01-25 15:45:09 -0800 |
| commit | 0179c6b07f7ed2f3ea7309596169e15a59e7ee0e (patch) | |
| tree | e5077edbc3e5c98a999a50cb152b081423333437 /drivers/android/binder_alloc.c | |
| parent | 9e59dd458a6e616c12312fc2d80b4de2b904bd9f (diff) | |
xen-netback: don't produce zero-size SKB frags
commit c7ec4f2d684e17d69bbdd7c4324db0ef5daac26a upstream.
While frontends may submit zero-size requests (wasting a precious slot),
core networking code as of at least 3ece782693c4b ("sock: skb_copy_ubufs
support for compound pages") can't deal with SKBs when they have all
zero-size fragments. Respond to empty requests right when populating
fragments; all further processing is fragment based and hence won't
encounter these empty requests anymore.
In a way this should have been that way from the beginning: When no data
is to be transferred for a particular request, there's not even a point
in validating the respective grant ref. That's no different from e.g.
passing NULL into memcpy() when at the same time the size is 0.
This is XSA-448 / CVE-2023-46838.
Cc: stable@vger.kernel.org
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/android/binder_alloc.c')
0 files changed, 0 insertions, 0 deletions