CVE-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 •
CVE-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 •
CVE-2023-52500 – scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command
https://notcve.org/view.php?id=CVE-2023-52500
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed when we receive the response. • https://git.kernel.org/stable/c/2afd8fcee0c4d65a482e30c3ad2a92c25e5e92d4 https://git.kernel.org/stable/c/d540a4370aba378fbedf349ba0bb68e96e24243d https://git.kernel.org/stable/c/2259e1901b2d8c0e8538fc99e77de443b939e749 https://git.kernel.org/stable/c/22e6d783a33015bcdf0979015e4eac603912bea7 https://git.kernel.org/stable/c/c13e7331745852d0dd7c35eabbe181cbd5b01172 •
CVE-2022-48628 – ceph: drop messages from MDS when unmounting
https://notcve.org/view.php?id=CVE-2022-48628
In the Linux kernel, the following vulnerability has been resolved: ceph: drop messages from MDS when unmounting When unmounting all the dirty buffers will be flushed and after the last osd request is finished the last reference of the i_count will be released. Then it will flush the dirty cap/snap to MDSs, and the unmounting won't wait the possible acks, which will ihold the inodes when updating the metadata locally but makes no sense any more, of this. This will make the evict_inodes() to skip these inodes. If encrypt is enabled the kernel generate a warning when removing the encrypt keys when the skipped inodes still hold the keyring: WARNING: CPU: 4 PID: 168846 at fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0 CPU: 4 PID: 168846 Comm: umount Tainted: G S 6.1.0-rc5-ceph-g72ead199864c #1 Hardware name: Supermicro SYS-5018R-WR/X10SRW-F, BIOS 2.0 12/17/2015 RIP: 0010:fscrypt_destroy_keyring+0x7e/0xd0 RSP: 0018:ffffc9000b277e28 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff88810d52ac00 RCX: ffff88810b56aa00 RDX: 0000000080000000 RSI: ffffffff822f3a09 RDI: ffff888108f59000 RBP: ffff8881d394fb88 R08: 0000000000000028 R09: 0000000000000000 R10: 0000000000000001 R11: 11ff4fe6834fcd91 R12: ffff8881d394fc40 R13: ffff888108f59000 R14: ffff8881d394f800 R15: 0000000000000000 FS: 00007fd83f6f1080(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f918d417000 CR3: 000000017f89a005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> generic_shutdown_super+0x47/0x120 kill_anon_super+0x14/0x30 ceph_kill_sb+0x36/0x90 [ceph] deactivate_locked_super+0x29/0x60 cleanup_mnt+0xb8/0x140 task_work_run+0x67/0xb0 exit_to_user_mode_prepare+0x23d/0x240 syscall_exit_to_user_mode+0x25/0x60 do_syscall_64+0x40/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd83dc39e9b Later the kernel will crash when iput() the inodes and dereferencing the "sb->s_master_keys", which has been released by the generic_shutdown_super(). • https://git.kernel.org/stable/c/89744b64914426cbabceb3d8a149176b5dafdfb5 https://git.kernel.org/stable/c/47f82395f04a976d4fa97de7f2acffa1c1096571 https://git.kernel.org/stable/c/e3dfcab2080dc1f9a4b09cc1327361bc2845bfcd •
CVE-2022-48627 – vt: fix memory overlapping when deleting chars in the buffer
https://notcve.org/view.php?id=CVE-2022-48627
In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vt: corrige la superposición de memoria al eliminar caracteres en el búfer. Se produce una copia de memoria superpuesta al eliminar una línea larga. • https://git.kernel.org/stable/c/81732c3b2fede049a692e58a7ceabb6d18ffb18c https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29 https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926 https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244 https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265 https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges •