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.
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
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
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.