CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52506 – LoongArch: Set all reserved memblocks on Node#0 at initialization
https://notcve.org/view.php?id=CVE-2023-52506
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Set all reserved memblocks on Node#0 at initialization After commit 61167ad5fecdea ("mm: pass nid to reserve_bootmem_region()") we get a panic if DEFERRED_STRUCT_PAGE_INIT is enabled: [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000002b82, era == 90000000040e3f28, ra == 90000000040e3f18 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #733 [ 0.000000] pc 90000000040e3f28 ra 90000000040e3f18 tp 90000000046f4000 sp 90000000046f7c90 [ 0.000000] a0 0000000000000001 a1 0000000000200000 a2 0000000000000040 a3 90000000046f7ca0 [ 0.000000] a4 90000000046f7ca4 a5 0000000000000000 a6 90000000046f7c38 a7 0000000000000000 [ 0.000000] t0 0000000000000002 t1 9000000004b00ac8 t2 90000000040e3f18 t3 90000000040f0800 [ 0.000000] t4 00000000000f0000 t5 80000000ffffe07e t6 0000000000000003 t7 900000047fff5e20 [ 0.000000] t8 aaaaaaaaaaaaaaab u0 0000000000000018 s9 0000000000000000 s0 fffffefffe000000 [ 0.000000] s1 0000000000000000 s2 0000000000000080 s3 0000000000000040 s4 0000000000000000 [ 0.000000] s5 0000000000000000 s6 fffffefffe000000 s7 900000000470b740 s8 9000000004ad4000 [ 0.000000] ra: 90000000040e3f18 reserve_bootmem_region+0xec/0x21c [ 0.000000] ERA: 90000000040e3f28 reserve_bootmem_region+0xfc/0x21c [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010800 [PIL] (IS=11 ECode=1 EsubCode=0) [ 0.000000] BADV: 0000000000002b82 [ 0.000000] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [ 0.000000] Modules linked in: [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [ 0.000000] Stack : 0000000000000000 9000000002eb5430 0000003a00000020 90000000045ccd00 [ 0.000000] 900000000470e000 90000000002c1918 0000000000000000 9000000004110780 [ 0.000000] 00000000fe6c0000 0000000480000000 9000000004b4e368 9000000004110748 [ 0.000000] 0000000000000000 900000000421ca84 9000000004620000 9000000004564970 [ 0.000000] 90000000046f7d78 9000000002cc9f70 90000000002c1918 900000000470e000 [ 0.000000] 9000000004564970 90000000040bc0e0 90000000046f7d78 0000000000000000 [ 0.000000] 0000000000004000 90000000045ccd00 0000000000000000 90000000002c1918 [ 0.000000] 90000000002c1900 900000000470b700 9000000004b4df78 9000000004620000 [ 0.000000] 90000000046200a8 90000000046200a8 0000000000000000 9000000004218b2c [ 0.000000] 9000000004270008 0000000000000001 0000000000000000 90000000045ccd00 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<90000000040e3f28>] reserve_bootmem_region+0xfc/0x21c [ 0.000000] [<900000000421ca84>] memblock_free_all+0x114/0x350 [ 0.000000] [<9000000004218b2c>] mm_core_init+0x138/0x3cc [ 0.000000] [<9000000004200e38>] start_kernel+0x488/0x7a4 [ 0.000000] [<90000000040df0d8>] kernel_entry+0xd8/0xdc [ 0.000000] [ 0.000000] Code: 02eb21ad 00410f4c 380c31ac <262b818d> 6800b70d 02c1c196 0015001c 57fe4bb1 260002cd The reason is early memblock_reserve() in memblock_init() set node id to MAX_NUMNODES, making NODE_DATA(nid) a NULL dereference in the call chain reserve_bootmem_region() -> init_reserved_page(). After memblock_init(), those late calls of memblock_reserve() operate on subregions of memblock .memory regions. As a result, these reserved regions will be set to the correct node at the first iteration of memmap_init_reserved_pages(). So set all reserved memblocks on Node#0 at initialization can avoid this panic. • https://git.kernel.org/stable/c/f105e893a8edd48bdf4bef9fef845a9ff402f737 https://git.kernel.org/stable/c/19878758accf6b2788091a771d9f9fee7bab11ab https://git.kernel.org/stable/c/b795fb9f5861ee256070d59e33130980a01fadd7 •
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 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52498 – PM: sleep: Fix possible deadlocks in core system-wide PM code
https://notcve.org/view.php?id=CVE-2023-52498
In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: suspensión: soluciona posibles bloqueos en el código PM de todo el sistema central. Se informa que en situaciones de poca memoria, el código central de reanudación de todo el sistema se bloquea porque async_schedule_dev() ejecuta su el argumento funciona sincrónicamente si no puede asignar memoria (y no solo en ese caso) y esa función intenta adquirir un mutex que ya está retenido. La ejecución de la función de argumento sincrónicamente desde dpm_async_fn() también puede ser problemática por razones de pedido (puede causar que la devolución de llamada de currículum de un dispositivo consumidor se invoque antes que la de un dispositivo proveedor requerido, por ejemplo). • https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0 https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34 https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7 https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •