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.
Created kernel tracking bugs for this issue:
Affects: fedora-all [bug 2120596]
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!
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):
Alex, did you saw the comment from Steve Beattie?
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
> 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.