CVE-2022-48819
published 2024-07-16CVE-2022-48819: In the Linux kernel, the following vulnerability has been resolved: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case syzbot found that mixing…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.23%
13.8th percentile
In the Linux kernel, the following vulnerability has been resolved:
tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY)
calls over the same TCP socket would again trigger the
infamous warning in inet_sock_destruct()
WARN_ON(sk_forward_alloc_get(sk));
While Talal took into account a mix of regular copied data
and MSG_ZEROCOPY one in the same skb, the sendpage() path
has been forgotten.
We want the charging to happen for sendpage(), because
pages could be coming from a pipe. What is missing is the
downgrading of pure zerocopy status to make sure
sk_forward_alloc will stay synced.
Add tcp_downgrade_zcopy_pure() helper so that we can
use it from the two callers.
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.16.10-1 (bookworm) | linux 5.16.10-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 9b65b17db72313b7a4fe9bc9502928c88be57986 < 47f3860c4931175f112f28dcac66eacca9b1040f | 47f3860c4931175f112f28dcac66eacca9b1040f |
| linux | linux | >= 9b65b17db72313b7a4fe9bc9502928c88be57986 < f8d9d938514f46c4892aff6bfe32f425e84d81cc | f8d9d938514f46c4892aff6bfe32f425e84d81cc |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 5.16 < 5.16.10 | 5.16.10 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
vendor_redhat·2024-07-16·CVSS 5.5
CVE-2022-48819 [MEDIUM] CWE-99 kernel: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
kernel: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
In the Linux kernel, the following vulnerability has been resolved:
tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY)
calls over the same TCP socket would again trigger the
infamous warning in inet_sock_destruct()
WARN_ON(sk_forward_alloc_get(sk));
While Talal took into account a mix of regular copied data
and MSG_ZEROCOPY one in the same skb, the sendpage() path
has been forgotten.
We want the charging to happen for sendpage(), because
pages could be coming from a pipe. What is missing is the
downgrading of pure zerocopy status to make sure
sk_forward_alloc will stay synced.
Add tcp_downgrade_zcopy_pure() helper so that we can
use it from the two cal
Debian
CVE-2022-48819: linux - In the Linux kernel, the following vulnerability has been resolved: tcp: take c...
vendor_debian·2022·CVSS 5.5
CVE-2022-48819 [MEDIUM] CVE-2022-48819: linux - In the Linux kernel, the following vulnerability has been resolved: tcp: take c...
In the Linux kernel, the following vulnerability has been resolved: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY) calls over the same TCP socket would again trigger the infamous warning in inet_sock_destruct() WARN_ON(sk_forward_alloc_get(sk)); While Talal took into account a mix of regular copied data and MSG_ZEROCOPY one in the same skb, the sendpage() path has been forgotten. We want the charging to happen for sendpage(), because pages could be coming from a pipe. What is missing is the downgrading of pure zerocopy status to make sure sk_forward_alloc will stay synced. Add tcp_downgrade_zcopy_pure() helper so that we can use it from the two callers.
Scope: local
bookworm: resolved (fixed in 5.16.10-1)
bullseye:
GHSA
GHSA-9pvc-v9gg-mq34: In the Linux kernel, the following vulnerability has been resolved:
tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
syzbot found that mi
ghsa_unreviewed·2024-07-16
CVE-2022-48819 [MEDIUM] GHSA-9pvc-v9gg-mq34: In the Linux kernel, the following vulnerability has been resolved:
tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
syzbot found that mi
In the Linux kernel, the following vulnerability has been resolved:
tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY)
calls over the same TCP socket would again trigger the
infamous warning in inet_sock_destruct()
WARN_ON(sk_forward_alloc_get(sk));
While Talal took into account a mix of regular copied data
and MSG_ZEROCOPY one in the same skb, the sendpage() path
has been forgotten.
We want the charging to happen for sendpage(), because
pages could be coming from a pipe. What is missing is the
downgrading of pure zerocopy status to make sure
sk_forward_alloc will stay synced.
Add tcp_downgrade_zcopy_pure() helper so that we can
use it from the two callers.
OSV
CVE-2022-48819: In the Linux kernel, the following vulnerability has been resolved: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case syzbot found that mixi
osv·2024-07-16·CVSS 5.5
CVE-2022-48819 [MEDIUM] CVE-2022-48819: In the Linux kernel, the following vulnerability has been resolved: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case syzbot found that mixi
In the Linux kernel, the following vulnerability has been resolved: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY) calls over the same TCP socket would again trigger the infamous warning in inet_sock_destruct() WARN_ON(sk_forward_alloc_get(sk)); While Talal took into account a mix of regular copied data and MSG_ZEROCOPY one in the same skb, the sendpage() path has been forgotten. We want the charging to happen for sendpage(), because pages could be coming from a pipe. What is missing is the downgrading of pure zerocopy status to make sure sk_forward_alloc will stay synced. Add tcp_downgrade_zcopy_pure() helper so that we can use it from the two callers.
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2024-07-16
Published