Bug 2298158 (CVE-2022-48819)

Summary:	CVE-2022-48819 kernel: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	dfreiber, drow, jburrell, vkumar
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	kernel 5.16.10, kernel 5.17	Doc Type:	If docs needed, set a value
Doc Text:	In the Linux kernel, a vulnerability has been identified related to TCP handling. The issue arises when mixing sendpage() and sendmsg(MSG_ZEROCOPY) calls over the same TCP socket, which can trigger a warning in inet_sock_destruct(). This may lead to synchronization issues.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2024-07-16 12:47:48 UTC

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.