Bug 1202660 - (CVE-2022-2961) VUL-0: CVE-2022-2961: kernel: race condition in rose_bind()
(CVE-2022-2961)
VUL-0: CVE-2022-2961: kernel: race condition in rose_bind()
Status: NEW
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Minor
: ---
Assigned To: Takashi Iwai
Security Team bot
https://smash.suse.de/issue/340532/
CVSSv3.1:SUSE:CVE-2022-2961:6.5:(AV:L...
:
Depends on:
Blocks: CVE-2022-1247
  Show dependency treegraph
 
Reported: 2022-08-24 07:02 UTC by Robert Frohl
Modified: 2023-03-24 13:01 UTC (History)
6 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Frohl 2022-08-24 07:02:44 UTC
rh#2120595

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.

References:
https://bugzilla.redhat.com/show_bug.cgi?id=2120595
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-2961
Comment 3 Takashi Iwai 2022-08-25 15:03:11 UTC
I'll wait for a bit more information update.
Comment 5 Takashi Iwai 2022-10-17 12:36:06 UTC
Still no movement in the upstream...
Comment 6 Petr Mladek 2022-11-16 15:48:09 UTC
I still do not see any related fix in net/rose/ in upstream.
Comment 7 Takashi Iwai 2022-12-01 14:05:21 UTC
No upstream development about this bug yet, unfortunately.
Comment 10 Petr Mladek 2023-03-03 13:10:06 UTC
Is there any movement upstream, please?
Comment 17 Robert Frohl 2023-03-10 08:25:59 UTC
Only affects kernel-*-optional packages which are shipped with Leap only.
Comment 18 Petr Mladek 2023-03-10 09:08:10 UTC
I wonder if it would be good enough to make a comment in supported.conf.
Anyone would need to touch the line if the module is moved from
the -optional package.

Adding also Martin Doucha into Cc. I wonder if there might be an
"easy" way to catch when the "rose" module is distributed with SLES
on the QA side.
Comment 19 Takashi Iwai 2023-03-10 09:11:47 UTC
(In reply to Petr Mladek from comment #18)
> I wonder if it would be good enough to make a comment in supported.conf.
> Anyone would need to touch the line if the module is moved from
> the -optional package.

Sounds like a good idea.  We can mention the pending CVEs there.