Bug 2120595 (CVE-2022-2961)

Summary:	CVE-2022-2961 kernel: race condition in rose_bind()
Product:	[Other] Security Response	Reporter:	Alex <allarkin>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	acaringi, adscvr, airlied, alciregi, bhu, brdeoliv, bskeggs, carnil, chwhite, crwood, ddepaula, debarbos, dhoward, dvlasenk, fhrbata, hdegoede, hkrzesin, hpa, jarod, jarodwilson, jburrell, jfaracco, jferlan, jforbes, jglisse, jlelli, joe.lawrence, jonathan, josef, jpazdziora, jshortt, jstancek, jwboyer, jwyatt, kcarcia, kernel-maint, kernel-mgr, lgoncalv, linville, lleshchi, lzampier, masami256, mchehab, nmurray, ptalbert, qzhao, rvrbovsk, scweaver, steve.beattie, steved, tyberry, vkumar, walters, williams
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	Linux kernel 6.0-rc2	Doc Type:	If docs needed, set a value
Doc Text:	A use-after-free flaw was found in the Linux kernel’s PLP Rose functionality in the way a user triggers a race condition by calling bind while simultaneously triggering the rose_bind() function. This flaw allows a local user to crash or potentially escalate their privileges on the system.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-09-02 16:55:53 UTC	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:	2120596
Bug Blocks:	2060938

Description Alex 2022-08-23 11:20:21 UTC

A flaw use after free in the Linux Kernel found in the Amateur Radio X.25 Packet Layer Protocol (PLP Rose).

The bug is race condition inside rose_bind() function. The rose_bind() binds an sk and a given address, and then adds the sk to rose_list via rose_insert_socket(). Since there is no lock_sock() in rose_bind(), a user can call rose_bind() from two threads at the same moment, and the victim sk is possible to be added to rose_list twice.

If the race is succeed, sk->sk_node.next will point to sk itself, which makes it become a cycle, and the sk's refcount is one more than the normal
case. When releasing the sk, according to rose_destroy_socket(), rose_remove_socket() is called multiple times which is up to sk_has_allocations(). If sk_has_allocations() returns false the first time, sk won't be freed and cause a memory leak. Otherwise, sk is freed but can still be accessed via rose_list, which causes a use-after-free. An attacker is able to leak kernel information from /proc/net/rose* and do local privilege escalation in other ways.

Tested it on Linux-5.17.rc5.

Comment 1 Alex 2022-08-23 11:20:44 UTC

Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 2120596]

Comment 4 Steve Beattie 2022-08-30 05:58:40 UTC

Alex, I see you've asserted that this issue is fixed in 6.0-rc2. I'm not seeing a fix between 6.0-rc1 and rc2 that addresses the issue, is it 2df91e397d85 ("net: rose: add netdev ref tracker to 'struct rose_sock'") that landed in 6.0-rc1, some other commit, or has a fix not landed yet upstream?

Thanks for any clarity you can give!

Comment 5 Product Security DevOps Team 2022-09-02 16:55:49 UTC

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2022-2961

Comment 6 Salvatore Bonaccorso 2022-09-04 19:20:08 UTC

Alex, did you saw the comment from Steve Beattie?

Comment 7 Alex 2022-09-05 07:38:46 UTC

In reply to comment #4:
> Alex, I see you've asserted that this issue is fixed in 6.0-rc2. I'm not
> seeing a fix between 6.0-rc1 and rc2 that addresses the issue, is it
> 2df91e397d85 ("net: rose: add netdev ref tracker to 'struct rose_sock'")
> that landed in 6.0-rc1, some other commit, or has a fix not landed yet
> upstream?
> 
> Thanks for any clarity you can give!

It is not yet fixed in the 6.0-rc1/rc2.
I use for this field version where already fixed or last known affected version, because similar for the Version of the CVE from cveform.mitre.org:
"Known affected or fixed in versions of the product/component. This information is often available on the flaw bug on the fixedin field".

When fixed, probably good idea to update "fixedin field" field here.

Comment 8 Jan Pazdziora (Red Hat) 2023-07-29 06:40:42 UTC

Hello,

could this be reopened and proper investigation of the code in various RHEL kernel versions done? It is not clear on what analysis the Not affected conclusion in the CVE page https://access.redhat.com/security/cve/cve-2022-2961 was made and there are some concerns above if we have a fix and where at all.

Thank you, Jan

Comment 9 Alex 2023-07-30 13:10:08 UTC

In reply to comment #8:
> Hello,
> 
> could this be reopened and proper investigation of the code in various RHEL
> kernel versions done? It is not clear on what analysis the Not affected
> conclusion in the CVE page
> https://access.redhat.com/security/cve/cve-2022-2961 was made and there are
> some concerns above if we have a fix and where at all.
> 
> Thank you, Jan

Hi Jan,

The code already properly investigated by two persons: Mauro (analyst) and Petr (security arhitect).

I added statement: "The Kernel config param CONFIG_AX25 enabled only for Fedora, so all versions of Red Hat Enterprise Linux are not affected.".

Regards,
Alex

Comment 10 Jan Pazdziora (Red Hat) 2023-07-31 08:25:32 UTC

Great, thank you. As we and the evaluating lab don't have insight into the process outside of what is here or on the CVE pages, such a brief summary helps a lot.