Bug 2229498 (CVE-2023-4194)

Summary:	CVE-2023-4194 kernel: tap: tap_open(): correctly initialize socket uid next fix of i_uid to current_fsuid
Product:	[Other] Security Response	Reporter:	Alex <allarkin>
Component:	vulnerability	Assignee:	Nobody <nobody>
Status:	NEW ---	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	acaringi, allarkin, arachman, bhu, chwhite, crwood, dbohanno, ddepaula, debarbos, dfreiber, drow, dvlasenk, ezulian, hkrzesin, jarod, jburrell, jdenham, jfaracco, jferlan, jforbes, jlelli, joe.lawrence, jshortt, jstancek, jwyatt, kcarcia, kernel-mgr, ldoskova, lgoncalv, lveyde, lzampier, michal.skrivanek, mperina, nmurray, ptalbert, qzhao, rogbas, rrobaina, rvrbovsk, sbonazzo, scweaver, tglozar, vkumar, walters, wcosta, williams, wmealing, ycote, ymankad
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	kernel 6.5-rc5	Doc Type:	If docs needed, set a value
Doc Text:	A flaw was found in the Linux kernel's TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to not be accurate.	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:
Bug Depends On:	2229499, 2229505, 2229506, 2229507, 2229508
Bug Blocks:	2172923

Description Alex 2023-08-06 14:11:43 UTC

A flaw found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function.
While it will be often correct, as tuntap devices require CAP_NET_ADMIN, it may not always be the case, e.g., a non-root user only having that capability.
This would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters.
The original fix for the CVE-2023-1076 was incorrect. The problem is that the following upstream commits (that were fix for the CVE-2023-1076) - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to be entirely bogus.

References:
https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/
https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/
https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/

Comment 1 Alex 2023-08-06 14:12:11 UTC

Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 2229499]

Comment 5 Laszlo Ersek 2023-08-07 14:30:47 UTC

Upstream patches:

#1 9bc3047374d5 ("net: tun_chr_open(): set sk_uid from current_fsuid()", 2023-08-02)
#2 5c9241f3ceab ("net: tap_open(): set sk_uid from current_fsuid()", 2023-08-02)

Comment 6 errata-xmlrpc 2023-11-07 08:20:46 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2023:6583 https://access.redhat.com/errata/RHSA-2023:6583