Hide Forgot
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): https://access.redhat.com/security/cve/cve-2022-2961
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 > 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.