CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52505 – phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers
https://notcve.org/view.php?id=CVE-2023-52505
In the Linux kernel, the following vulnerability has been resolved: phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers The protocol converter configuration registers PCC8, PCCC, PCCD (implemented by the driver), as well as others, control protocol converters from multiple lanes (each represented as a different struct phy). So, if there are simultaneous calls to phy_set_mode_ext() to lanes sharing the same PCC register (either for the "old" or for the "new" protocol), corruption of the values programmed to hardware is possible, because lynx_28g_rmw() has no locking. Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take the global spinlock from the phy_ops :: set_mode() implementation. There are no other callers which modify PCC registers. • https://git.kernel.org/stable/c/8f73b37cf3fbda67ea1e579c3b5785da4e7aa2e3 https://git.kernel.org/stable/c/6f901f8448c6b25ed843796b114471d2a3fc5dfb https://git.kernel.org/stable/c/c2d7c79898b427d263c64a4841987eec131f2d4e https://git.kernel.org/stable/c/139ad1143151a07be93bf741d4ea7c89e59f89ce •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52504 – x86/alternatives: Disable KASAN in apply_alternatives()
https://notcve.org/view.php?id=CVE-2023-52504
In the Linux kernel, the following vulnerability has been resolved: x86/alternatives: Disable KASAN in apply_alternatives() Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine: BUG: KASAN: out-of-bounds in rcu_is_watching() Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0 ... __asan_load4() rcu_is_watching() trace_hardirqs_on() text_poke_early() apply_alternatives() ... On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled(). KASAN gets confused when apply_alternatives() patches the KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue. Fix it for real by disabling KASAN while the kernel is patching alternatives. [ mingo: updated the changelog ] • https://git.kernel.org/stable/c/6657fca06e3ffab8d0b3f9d8b397f5ee498952d7 https://git.kernel.org/stable/c/3719d3c36aa853d5a2401af9f8d6b116c91ad5ae https://git.kernel.org/stable/c/3770c38cd6a60494da29ac2da73ff8156440a2d1 https://git.kernel.org/stable/c/6788b10620ca6e98575d1e06e72a8974aad7657e https://git.kernel.org/stable/c/ecba5afe86f30605eb9dfb7f265a8de0218d4cfc https://git.kernel.org/stable/c/5b784489c8158518bf7a466bb3cc045b0fb66b4b https://git.kernel.org/stable/c/cd287cc208dfe6bd6da98e7f88e723209242c9b4 https://git.kernel.org/stable/c/d35652a5fc9944784f6f50a5c979518ff •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52503 – tee: amdtee: fix use-after-free vulnerability in amdtee_close_session
https://notcve.org/view.php?id=CVE-2023-52503
In the Linux kernel, the following vulnerability has been resolved: tee: amdtee: fix use-after-free vulnerability in amdtee_close_session There is a potential race condition in amdtee_close_session that may cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread tries to free this session via: kref_put(&sess->refcount, destroy_session); the reference count will get decremented, and the next step would be to call destroy_session(). However, if in another thread, amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may return 'sess' that will be freed up later in destroy_session() leading to use-after-free in amdtee_open_session. To fix this issue, treat decrement of sess->refcount and removal of 'sess' from session list in destroy_session() as a critical section, so that it is executed atomically. • https://git.kernel.org/stable/c/757cc3e9ff1d72d014096399d6e2bf03974d9da1 https://git.kernel.org/stable/c/da7ce52a2f6c468946195b116615297d3d113a27 https://git.kernel.org/stable/c/1680c82929bc14d706065f123dab77f2f1293116 https://git.kernel.org/stable/c/60c3e7a00db954947c265b55099c21b216f2a05c https://git.kernel.org/stable/c/1c95574350cd63bc3c5c2fa06658010768f2a0ce https://git.kernel.org/stable/c/f4384b3e54ea813868bb81a861bf5b2406e15d8f •
CVSS: 6.3EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52502 – net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()
https://notcve.org/view.php?id=CVE-2023-52502
In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn() Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF. Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock. nfc_llcp_sock_get_sn() has a similar problem. Finally nfc_llcp_recv_snl() needs to make sure the socket found by nfc_llcp_sock_from_sn() does not disappear. • https://git.kernel.org/stable/c/8f50020ed9b81ba909ce9573f9d05263cdebf502 https://git.kernel.org/stable/c/e863f5720a5680e50c4cecf12424d7cc31b3eb0a https://git.kernel.org/stable/c/7adcf014bda16cdbf804af5c164d94d5d025db2d https://git.kernel.org/stable/c/6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9 https://git.kernel.org/stable/c/d888d3f70b0de32b4f51534175f039ddab15eef8 https://git.kernel.org/stable/c/e4f2611f07c87b3ddb57c4b9e8efcd1e330fc3dc https://git.kernel.org/stable/c/d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c https://git.kernel.org/stable/c/31c07dffafce914c1d1543c135382a11f •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52501 – ring-buffer: Do not attempt to read past "commit"
https://notcve.org/view.php?id=CVE-2023-52501
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not attempt to read past "commit" When iterating over the ring buffer while the ring buffer is active, the writer can corrupt the reader. There's barriers to help detect this and handle it, but that code missed the case where the last event was at the very end of the page and has only 4 bytes left. The checks to detect the corruption by the writer to reads needs to see the length of the event. If the length in the first 4 bytes is zero then the length is stored in the second 4 bytes. But if the writer is in the process of updating that code, there's a small window where the length in the first 4 bytes could be zero even though the length is only 4 bytes. That will cause rb_event_length() to read the next 4 bytes which could happen to be off the allocated page. To protect against this, fail immediately if the next event pointer is less than 8 bytes from the end of the commit (last byte of data), as all events must be a minimum of 8 bytes anyway. • https://git.kernel.org/stable/c/cee5151c5410e868826b8afecfb356f3799ebea3 https://git.kernel.org/stable/c/344f2f3e61a90f0150c754796ec9a17fcaeec03d https://git.kernel.org/stable/c/b08a4938229dbb530a35c41b83002a1457c6ff49 https://git.kernel.org/stable/c/75fc9e99b3a71006720ad1e029db11a4b5c32d4a https://git.kernel.org/stable/c/95a404bd60af6c4d9d8db01ad14fe8957ece31ca •