New_entries

CVE-2022-48627

description

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.

中文

在Linux内核中，已解决以下漏洞：vt:fix删除缓冲区中的字符时内存重叠删除长行时发生内存重叠复制。当scr_memcpyw优化为memcpy时，此内存重叠副本可能会导致数据损坏，因为如果目标缓冲区与源缓冲区重叠，memcpy无法确保其行为。行缓冲区并不总是断开的，因为memcpy使用硬件加速，其结果是不确定的。通过使用scr_memmovew替换scr_memcpyw来解决此问题。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2022-48628

description

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 wont 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: 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().

中文

在Linux内核中，已解决以下漏洞：ceph:在卸载时从MDS中删除消息在卸载时，所有脏缓冲区都将被刷新，在最后一个osd请求完成后，i_count的最后一个引用将被释放。然后，它会将脏的cap/snap刷新到MDSs，并且卸载不会等待可能的acks，这将在本地更新元数据时占用inode，但这不再有意义。这将使reject_inodes（）跳过这些索引节点。如果启用了加密，当跳过的inode仍持有密钥环时，内核在删除加密密钥时会生成警告：警告：CPU:4 PID:168846 at fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0 CPU:4 PID：168846 Comm:umont-Tainted:G S 6.1.0-rc5-ceph-g72ead199864c#1硬件名称：Supermicro SYS-5018R-WR/X10SRW-F，BIOS 2.0 12/17/2015 RIP:0010：fscrypt-destroy_keyring+0x7e/0xd0RSP:0018:fffffc9000b277e28 EFLAGS:000010202 RAX:0000000000000000 2 RBX:ffff88810d52ac00 RCX:ffff 88810b56aa00 RDX:00000000080000000 RSI:ffffffff 822f3a09 RDI:ffffff 8881d394f59000 RBP:ffffff8881d394fb88 R08:0000000000000028 R09:000000000000000000000000 R10:000000000000000 1 R11:11ff4f6834fcd91 R12:ffffffff888 1d394fc40 R13:ffffff 888 108f59000 R14:fffffff888 1d394f800 R15:0000000000000000 fs:00007fd83f6f1 080（0000）GS:fffff88885fd00000（0000）knlGS:0000000000000000 CS:0010 DS:0000 ES:0000 CR0:00000000 80050033 CR2:00007f918d417000 CR3:0000000 17f89a005 CR4:0000000000 3706e0 DR0:0000000000000000 DR1:00000000 DR2:00000000 DR3:00000000 DR6:00000000 fffe0f0 DR7:0000000000000400调用跟踪：generic_shutdown_super+0x47/0x120 kill_anon_super+0x14/0x30 ceph_kill_sb+0x36/0x90[ceph]deactivate_locked_super+0.x29/0x60 cleanup_mnt+0xb8/0x140 TASK_work_run+0x67/0xb0 exit_to_user_mode_prepare+0x23d/0x240 syscall_exit_user_mode+0x25/0x60 do_syscall_64+0x40/0x80 entry_syscall_64_after_hwframe+0x63/0xcd RIP:003:00x7fd83dc39e9b稍后，当iput（）索引节点并取消引用“sb->s_master_keys”（已由general_shutdown_super（）释放）时，内核将崩溃。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52499

description

In the Linux kernel, the following vulnerability has been resolved: powerpc/47x: Fix 47x syscall return crash Eddie reported that newer kernels were crashing during boot on his 476 FSP2 system: kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0) BUG: Unable to handle kernel instruction fetch Faulting instruction address: 0xb7ee2000 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K FSP-2 Modules linked in: CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1 Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2 NIP: b7ee2000 LR: 8c008000 CTR: 00000000 REGS: bffebd83 TRAP: 0400 Not tainted (6.1.55-d23900f.ppcnf-fs p2) MSR: 00000030 <IR,DR> CR: 00001000 XER: 20000000 GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000 GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000 GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0 GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0 NIP [b7ee2000] 0xb7ee2000 LR [8c008000] 0x8c008000 Call Trace: Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX —[ end trace 0000000000000000 ]— The problem is in ret_from_syscall where the check for icache_44x_need_flush is done. When the flush is needed the code jumps out-of-line to do the flush, and then intends to jump back to continue the syscall return. However the branch back to label 1b doesnt return to the correct location, instead branching back just prior to the return to userspace, causing bogus register values to be used by the rfi. The breakage was introduced by commit 6f76a01173cc (“powerpc/syscall: implement system call entry/exit logic in C for PPC32”) which inadvertently removed the “1” label and reused it elsewhere. Fix it by adding named local labels in the correct locations. Note that the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n compiles.

中文

在Linux内核中，以下漏洞已被解决：powerpc/47x修复47x系统调用返回崩溃Eddie报告说，在他的476 FSP2系统上启动时，较新的内核崩溃：内核试图执行用户页面（b7ee2000）-试图利用漏洞？（uid:0）BUG：无法处理内核指令获取故障指令地址：0xb7ee2000 Oops：坏区域的内核访问，sig:11[#1]BE PAGE_SIZE=4K FSP-2链接的模块：CPU:0 PID:61 Comm:mount未受污染的6.1.55-d23900f.ppcnf-fsp2#1硬件名称：ibm，fsp2 476fpe 0x7ff520c0 FSP-2 NIP:b7ee2000 LR:8c008000 CTR:000000000 REGS:bffebd83 TRAP:0400未受污染（6.1.55-d23900f.ppcnf-fs p2）MSR:00000030<IR，DR>CR:00001000 XER:20000000 GPR00:c00110ac bffeb63 bffeb7e bffeb88 8c008000 00001000 00000d12 b7ee2000 GPR08:00000033 00000000 c139df10 48224824 1016c314 10160000 00000000 GPR16:10160000 10160000 0000000 8 00000000 1016000000000000 10160000 1016f5b0 GPR24:1017fa50 1017f4f740 1017f630 00000000 1017f4f4f0 NIP[b7ee2000]0xb7ee2 LR[8c008000]0x8c008000调用跟踪：指令转储：XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX XXXXXXXX XXXXXXXXXX XXXXXXXX-XXXXXXXXXXXXXXXXXX–[结束跟踪000000000000000000000000]–问题出现在ret_from_syscall中，在该调用中检查icache_44x_need_flush。当需要刷新时，代码会跳出行进行刷新，然后打算跳回来继续系统调用返回。然而，返回到标签1b的分支并没有返回到正确的位置，而是在返回到用户空间之前返回分支，导致rfi使用虚假的寄存器值。提交6f76a01173cc（“powerpc/syscall:在C中实现PPC32的系统调用入口/出口逻辑”）无意中删除了“1”标签并在其他地方重新使用了它，从而导致了破坏。通过在正确的位置添加命名的本地标签来解决此问题。请注意，返回标签需要位于ifdef之外，以便CONFIG_PPC_47x=n进行编译。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52500

description

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.

中文

在Linux内核中，已解决以下漏洞：scsi:pm80xx:在处理OPC_INB_SET_CONTROLLER_CONFIG命令时避免泄漏标记。当我们收到响应时，需要释放为OPC_INB_SET_CONTROLLER_CONFIG命令分配的标记。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52501

description

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. Theres 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, theres 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.

中文

在Linux内核中，已解决以下漏洞：环形缓冲区：不要试图读取过去的“提交”当环形缓冲区处于活动状态时对环形缓冲区进行迭代时，写入程序可能会损坏读取器。有一些障碍可以帮助检测和处理它，但该代码错过了最后一个事件位于页面末尾且只剩下4个字节的情况。检测写入程序对读取的损坏的检查需要查看事件的长度。如果前4个字节中的长度为零，则该长度存储在第二个4个字节。但是，如果编写器正在更新代码，则会有一个小窗口，其中前4个字节的长度可能为零，即使长度只有4个字节。这将导致rb_event_length（）读取接下来的4个字节，这些字节可能恰好偏离了分配的页面。为了防止这种情况发生，如果下一个事件指针距离提交结束（数据的最后一个字节）小于8个字节，请立即失败，因为所有事件都必须至少为8个字节。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52502

description

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.

中文

在Linux内核中，已解决以下漏洞：net:nfc:fix在nfc_llcp_sock_get（）和nfc_llcp_sock_get_sn（）中的争用Sili Luo报告在nfc_llcp_sock_get（）中出现争用，导致UAF。在持有锁的情况下，应在释放锁之前获取查找中找到的套接字的引用。nfc_llcp_sock_get_sn（）也有类似的问题。最后，nfc_llcp_recv_snl（）需要确保nfc_llcp_sock_from_sn（）找到的套接字不会消失。

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52503

description

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.

中文

在Linux内核中，以下漏洞已得到解决：tee:amdtee:修复amdtee_close_session中的释放后使用漏洞amdtee_close_session中存在潜在的竞争条件，可能导致amdtee_open_session中释放后使用。例如，如果一个会话的refcount==1，并且一个线程试图通过：kref_put（&sess->refcount，destroy_session）释放该会话；引用计数将递减，下一步将调用destroysession（）。但是，如果在另一个线程中，在destroy_session（）完成执行之前调用了amdte_open_session（。要解决此问题，请将destroy_session（）中sess->refcount的递减和从会话列表中删除sess视为关键部分，以便以原子方式执行。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52504

description

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 ]

中文

在Linux内核中，已解决以下漏洞：x86/alternatives:Disable KASAN In apply_alternatives（__asan_load4（）rc_is_watching（）trace_hardirqs_on（）text_poke_early（）apply_alternatives（）。。。在具有5级分页的机器上，cpu_feature_enabled（X86_feature_LA57）会得到修补。它包括KASAN代码，其中KASAN_SHADOW_START依赖于用cpu_feature_enabled（）定义的__VIRTUAL_MASK_SHIFT。当apply_alternatives（）修补KASAN_SHADOW_START用户时，KASAN会感到困惑。通过将__VIRTUAL_MASK_SHIFT替换为56，使KASAN_SHADOW_START成为静态的测试补丁可以解决此问题。当内核正在修补替代方案时，通过禁用KASAN来真正修复它。[mingo:更新了变更日志]

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52505

description

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.

中文

在Linux内核中，已解决以下漏洞：phy:lynx-28g:serialize concurrent phy_set_mode_ext（）calls to shared registers协议转换器配置寄存器PCC8、PCCC、PCCD（由驱动程序实现）以及其他寄存器，控制来自多个通道的协议转换器（每个通道表示为不同的结构phy）。因此，如果同时调用phy_set_mode_ext（）到共享同一PCC寄存器的通道（对于“旧”或“新”协议），则编程到硬件的值可能会损坏，因为lynx_28g_rmw（）没有锁定。在所有通道共享的结构lynx_28g_priva中添加一个spinlock，并从phy_ops:：set_mode（）实现中获取全局spinlock。没有其他呼叫者修改PCC寄存器。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52506

description

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.

中文

在Linux内核中，已解决以下漏洞：LoongArch：在初始化时设置节点#0上的所有保留内存块在提交61167ad5fecdea（“mm:pass nid to reserve_bootmem_region（）”）之后，如果启用了DEFERRED_STRUCT_PAGE_INIT，我们会感到恐慌：[0000000]CPU 0无法处理虚拟地址000000000000 2b82处的内核分页请求，era==9000000040e3f28，ra=900000000040e3f18[0.000000]错误[#1]：[0.000000]CPU:0 PID:0通信：交换未受污染6.5.0+#733[0.000000]pc 900000000040E3f28 ra 900000000040e3f18 tp 900000000046f4000 sp 900000000046f7c90[0.000000]a0 000000000000000 1 a1 0000000000 200000 a2 0000000000000040 a3 90000000046f7ca0[0.000000]a4 9000000046f7ca4 a5 00000000000000000000000000000000 a6 9000000046f 7c38 a7 000000000000000000000000000000]t0 000000000000000 2 t1 900000000 4b00ac8 t2 900000000 40e3f18 t3 900000000 40f0800[0.000000]t4 00000000000 f0000 t5 80000000 ffffe07e t6 000000000000000 3 t7 900000047 fff5e20[0.000000]t8 aaaaaaaaa b u0 0000000000000018 s9 0000000000000000 s0 fffffff efffe000000[0.000000]s1 0000000000000000 s2 0000000000000080 s3 0000000000000040 s4 0000000000000000000000s50000000000000000 s6 fffff efffe000000s7900000000 470b740 s8 900000000 4ad4000[0.000000]ra:9900000040e3f18 reserve_bootmem_region+0xec/0x21c[0.000000]ERA:9000000040e3f28 reserve_bootmem_reregion+0xfc/0x21c[0.000000]CRMD:0000000b0（PLV0-IE-DA+PG DACF=CC DACM=CC-WE）[0.000000]PRMD:0000000（PPLV0-PIE-PWE）[0.000000]EUEN:0000000 E-SXE-ASXE-BTE）[0.000000]ECFG:00070800（LIE=11 VS=7）[0.000000]ESTAT:000010800[PIL]（IS=11 ECode=1 EsubCode=0）[0.000000]BADV:0000000000000 2b82[0.000000]PRID:0014d000（龙芯-64bit，龙芯-3A6000）[0.00000]链接在中的模块：[0.000000]进程交换程序（pid:0，线程信息=（prtval），任务=（ptrval_））[0000000]堆栈：00000000000000009000000000eb5430000003a000000020 900000000045ccd00[0000000]9000000000470e000 90000000002c1918 0000000090000000004110780[0000000]00000000 fe6c0000 00000048000000090000000004b4e368 900000004110748[0000000]000000000000009000000000421ca8490000000004620000 90000000004564970[0000000]90000000046f7d78 9000000000cc9f70 90000000002c1918 9000000000470e000【000000】90000000004564970 900000000040bc0e0 900000000046f7d 0000000000000000【0.0000】00000000 4000 900000000045ccd 00000000 90000000002c【0.00000】90000000002c1900 9000000000470b700 90000000004b4df78 9000000000462【0.000000】900000000046200a8 900000000046200 a8 00000000 9000000004218b2c【0.0000）90000000004270008 0000000000000001 00000000000000900000000045ccd00[0000000]。。。[0.000000]调用跟踪：[0.000000][<900000000040e3f28>]reserve_bootmem_region+0xfc/0x21c[0.00000000][<900000000421ca84>]memblock_free_all+0x114/0x350[0.000000][<900000004218b2c>]mm_core_init+0x138/0x3cc[0.000000][<900000004200e38>]start_kernel+0x488/0x7a4[0.000000][<900000000040df0d8>]kernel_entry+0xd8/0xdc[0.000000][0.00000000]代码：02eb21ad 00410f4c 380c31ac<262b818d>6800b70d 02c1c196 0015001c 57fe4bb1 260002cd原因是早期memblock_init（）中的memblock_reserve（）将节点id设置为MAX_NUMNODES，使node_DATA（nid）在调用链reserve_bootmem_region（）->init_reserved_page（）中为NULL解引用。在memblock_init（）之后，那些对memblock_reserve（）的后期调用在membloc.memory区域的子区域上操作。因此，在memmap_init_reserved_pages（）的第一次迭代中，这些保留区域将被设置为正确的节点。因此，在初始化时在节点#0上设置所有保留的内存块可以避免这种恐慌。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52507

description

In the Linux kernel, the following vulnerability has been resolved: nfc: nci: assert requested protocol is valid The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided protocol is less than the maximum defined so it doesnt potentially perform a shift-out-of-bounds and provide a clearer error for undefined protocols vs unsupported ones.

中文

在Linux内核中，已解决以下漏洞：nfc:nci:assert请求的协议有效该协议用于位掩码，以确定是否支持该协议。断言所提供的协议小于定义的最大值，这样它就不会潜在地执行越界转换，并为未定义的协议与不支持的协议提供更清晰的错误。

cvss epss percentile
None 0.04% 10.69%

references

CVE-2023-52508

description

In the Linux kernel, the following vulnerability has been resolved: nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid() The nvme_fc_fcp_op structure describing an AEN operation is initialized with a null request structure pointer. An FC LLDD may make a call to nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation. Add validation of the request structure pointer before dereference.

中文

在Linux内核中，已解决以下漏洞：nvme fc：防止nvme_fc_io_getuuid（）中的null指针取消引用描述AEN操作的nvme_fc_fcp_op结构是用null请求结构指针初始化的。FC LLDD可以对nvme_FC_io_getuuid进行调用，将指针传递到用于AEN操作的nvmefc_fcp_req。在取消引用之前添加对请求结构指针的验证。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52509

description

In the Linux kernel, the following vulnerability has been resolved: ravb: Fix use-after-free issue in ravb_tx_timeout_work() The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work() is possible to use the freed priv after ravb_remove() was called like below: CPU0 CPU1 ravb_tx_timeout() ravb_remove() unregister_netdev() free_netdev(ndev) // free priv ravb_tx_timeout_work() // use priv unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called, netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop().

中文

在Linux内核中，以下漏洞已被解决：rafb:修复ravb_tx_timeout_work（）中的释放后使用问题ravb_stop（）应调用cancel_work_sync（）。否则，ravb_tx_timeout_work（）可以在调用ravb_remove（）后使用释放的priv，如下所示：CPU0 CPU1 ravb_tx_timeout（）ravb_move（）unregister_netdev（ndev）//free-priv ravb_tx_timeout.work（。并且，在调用phy_stop（）之后，还会调用netif_carrier_off（）。这样就不会在phy_stop（）之后调用.ndo_tx_timeout（）。

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52510

description

In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: Fix a potential UAF in ca8210_probe If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().

中文

在Linux内核中，已解决以下漏洞：ieee802154:ca8210:修复ca8210_probe中潜在的UAF。如果of_clk_add_provider（）在ca8210_register_ext_clock（）中失败，它将调用clk_negister（）来释放priva->clk并返回错误。但是，调用方ca8210_probe（）随后调用ca8210_remove（），其中priva->clk在ca8210_unregister_ext_clock（）中再次释放。在这种情况下，在我们第二次调用clk_unregister（）时，free之后的使用可能会发生。通过删除第一个clk_unregister（）来修复此问题。此外，priva->clk可能是clk_register_fixed_rate（）失败时的错误代码。使用IS_ERR_OR_NULL在ca8210_unregister_ext_clock（）中捕获此情况。

cvss epss percentile
None 0.04% 10.69%

references

CVE-2023-52511

description

In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: reduce DMA RX transfer width to single byte Through empirical testing it has been determined that sometimes RX SPI transfers with DMA enabled return corrupted data. This is down to single or even multiple bytes lost during DMA transfer from SPI peripheral to memory. It seems the RX FIFO within the SPI peripheral can become confused when performing bus read accesses wider than a single byte to it during an active SPI transfer. This patch reduces the width of individual DMA read accesses to the RX FIFO to a single byte to mitigate that issue.

中文

在Linux内核中，已解决以下漏洞：spi:sun6i:将DMA RX传输宽度减少到单字节通过经验测试，已确定有时启用DMA的RX spi传输会返回损坏的数据。这在从SPI外围设备到存储器的DMA传输过程中减少到单个甚至多个字节丢失。在活动SPI传输期间，当执行比单个字节更宽的总线读取访问时，SPI外围设备内的RX FIFO似乎会变得混乱。此修补程序将对RX FIFO的单个DMA读取访问的宽度减少到单个字节，以缓解此问题。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52512

description

In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: wpcm450: fix out of bounds write Write into pctrl->gpio_bank happens before the check for GPIO index validity, so out of bounds write may happen. Found by Linux Verification Center (linuxtesting.org) with SVACE.

中文

在Linux内核中，已解决以下漏洞：pinctrl:nuvoton:wpcm450:fix越界写入pctrl->gpio_bank发生在检查gpio索引有效性之前，因此可能发生越界写入。由Linux验证中心（linuxtesting.org）与SVACE一起发现。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52513

description

In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix connection failure handling In case immediate MPA request processing fails, the newly created endpoint unlinks the listening endpoint and is ready to be dropped. This special case was not handled correctly by the code handling the later TCP socket close, causing a NULL dereference crash in siw_cm_work_handler() when dereferencing a NULL listener. We now also cancel the useless MPA timeout, if immediate MPA request processing fails. This patch furthermore simplifies MPA processing in general: Scheduling a useless TCP socket read in sk_data_ready() upcall is now surpressed, if the socket is already moved out of TCP_ESTABLISHED state.

中文

在Linux内核中，已解决以下漏洞：RDMA/siw：修复连接故障处理如果立即MPA请求处理失败，新创建的端点将取消侦听端点的链接，并准备删除。处理稍后TCP套接字关闭的代码没有正确处理这种特殊情况，导致在取消引用NULL侦听器时siw_cm_work_handler（）中出现NULL取消引用崩溃。如果立即MPA请求处理失败，我们现在也取消无用的MPA超时。这个补丁进一步简化了MPA的处理：如果套接字已经移出TCP_ESTAISHED状态，那么在sk_data_ready（）上调用中调度一个无用的TCP套接字读取现在将被取消。

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52514

description

In the Linux kernel, the following vulnerability has been resolved: x86/reboot: VMCLEAR active VMCSes before emergency reboot VMCLEAR active VMCSes before any emergency reboot, not just if the kernel may kexec into a new kernel after a crash. Per Intels SDM, the VMX architecture doesnt require the CPU to flush the VMCS cache on INIT. If an emergency reboot doesnt RESET CPUs, cached VMCSes could theoretically be kept and only be written back to memory after the new kernel is booted, i.e. could effectively corrupt memory after reboot. Opportunistically remove the setting of the global pointer to NULL to make checkpatch happy.

中文

在Linux内核中，以下漏洞已被解决：x86/reboot:VMCLEAR活动的VMCS在紧急重新启动之前VMCLEAR激活的VMCs在任何紧急重新启动之后都是活动的，而不仅仅是在内核可能在崩溃后执行到新内核时。根据Intels SDM，VMX体系结构不需要CPU在INIT上刷新VMCS缓存。如果紧急重新启动没有重置CPU，理论上可以保留缓存的VMS，并且只有在新内核启动后才能写回内存，即重新启动后可能会有效地损坏内存。有机会删除全局指针为NULL的设置，以使checkpatch满意。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52515

description

In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned.

中文

在Linux内核中，已解决以下漏洞：RDMA/srp:不要从srp_abort（）调用scsi_done（）在scmd_eh_abort_handler（）调用scsi LLD eh_abort_handler回调后，它将执行以下操作之一：*调用scsi_queue_insert（）。*调用scsi_finish_command（）。*调用scsi_eh_scmd_add（）。因此，SCSI中止处理程序不得调用SCSI_done（）。否则，以上所有操作都将在释放后触发使用。因此，请从srp_abort（）中删除scsi_done（）调用。在返回SUCCESS之前保留srp_free_req（）调用，因为如果返回SUCCESS，我们可能不会再看到该命令。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52516

description

In the Linux kernel, the following vulnerability has been resolved: dma-debug: dont call __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we dont acquire serial consoles port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8 ____do_softirq+0x18/0x24 … -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 … -> #0 (console_owner){-…}-{0:0}: __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 … Chain exists of: console_owner –> &port_lock_key –> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 —- —- lock(free_entries_lock); lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol —truncated—

中文

在Linux内核中，以下漏洞已被解决：dma调试：不要在free_entries_lock下调用__dma_entry_alloc_check_leak（）__dma_eentry_alloc_check（）调用printk->串行控制台输出（qcom geni）并在free_eentries_lock旋转锁下获取端口->lock，这是一个反向锁定依赖链，因为qcom_geni IRQ处理程序可以调用dma调试代码并在port->lock下获取free_entries_lock。将__dma_entry_alloc_check_leak（）调用移出free_entries_lock作用域，这样我们就不会获取其下的串行控制台端口->锁。修剪lockdepsplat：现有依赖链（按相反顺序）为：->#2（free_entries lock）{-.-.}-{2:2}：raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop:0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 handle_irq_event_percpu+0x110/0x244 handle_irq event_pecpu+0x20/0x54 handle_irq-event+0x50/0x88 handle fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler=0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8 do_softirq+0x18/0x24..->#1（&port_lock_key）{-.-.}-{2:2}：_raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emite+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _prink+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_gani_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_be_device+0xfc/0x114驱动程序_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc总线_for_each_drv+0xb0/0xd8 __device_aattach+0xe4/0x140 device_initial_probet+0x1c/0x28总线_probe_device+0x45/0xb0 device_add+0x538/0x668的设备添加+0x44/0x50的平台设备创建数据+0x94/0xc8的平台总线创建+0x270/0x404的平台人口+0xac/0xc4的平台人口开发e+0x60/0xac geni_se_probe+0x154/0x160平台_probe+0x70/0xc0…->#0（console_owner）{-…}-｛0:0｝：__lock_acquire+0xdf8/0x109c lock_acqquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emitt+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0x4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4[msm]msm_gem_pin_pages_locked+0x38/0xac[msm]msm_gem_pin_vma_locked+0x58/0x88[msm]msm_ioctl_gem_submit+0xde4/0x13ac[msm]drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50。。。链存在于：console_owner–>&port_lock_key–>free_entries_lock可能的不安全锁定场景：CPU0 CPU1——lock（free_entries _lock）；锁定（&port_lock_key）；锁定（free_entries_lock）；锁定（console_owner）；DEADLOCK调用跟踪：dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncirculal+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acqquire+0x234/0x284 console_flush_all+0x30/0x454 console–截断—

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52517

description

In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain Previously the transfer complete IRQ immediately drained to RX FIFO to read any data remaining in FIFO to the RX buffer. This behaviour is correct when dealing with SPI in interrupt mode. However in DMA mode the transfer complete interrupt still fires as soon as all bytes to be transferred have been stored in the FIFO. At that point data in the FIFO still needs to be picked up by the DMA engine. Thus the drain procedure and DMA engine end up racing to read from RX FIFO, corrupting any data read. Additionally the RX buffer pointer is never adjusted according to DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA mode is a bug. Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode. Also wait for completion of RX DMA when in DMA mode before returning to ensure all data has been copied to the supplied memory buffer.

中文

在Linux内核中，以下漏洞已被解决：spi:sun6i:修复DMA RX传输完成和RX FIFO排出之间的竞争以前，传输完成的IRQ立即排出到RX FIFO，以将FIFO中剩余的任何数据读取到RX缓冲区。在中断模式下处理SPI时，这种行为是正确的。然而，在DMA模式下，一旦所有要传输的字节都存储在FIFO中，传输完成中断仍然会触发。此时，FIFO中的数据仍然需要由DMA引擎拾取。因此，耗尽过程和DMA引擎最终会竞相从RX FIFO中读取，破坏任何读取的数据。此外，在DMA模式下，RX缓冲区指针永远不会根据DMA进度进行调整，因此在DMA模式中调用RX FIFO排出过程是一个错误。通过仅在中断模式下排出RX FIFO来修复DMA RX模式中的损坏。在DMA模式下等待RX DMA完成后再返回，以确保所有数据都已复制到提供的内存缓冲区。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52518

description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_codec: Fix leaking content of local_codecs The following memory leak can be observed when the controller supports codecs which are stored in local_codecs list but the elements are never freed: unreferenced object 0xffff88800221d840 (size 32): comm “kworker/u3:0”, pid 36, jiffies 4294898739 (age 127.060s) hex dump (first 32 bytes): f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff ……….!….. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [] __kmalloc+0x47/0x120 [] hci_codec_list_add.isra.0+0x2d/0x160 [] hci_read_codec_capabilities+0x183/0x270 [] hci_read_supported_codecs+0x1bb/0x2d0 [] hci_read_local_codecs_sync+0x3e/0x60 [] hci_dev_open_sync+0x943/0x11e0 [] hci_power_on+0x10d/0x3f0 [] process_one_work+0x404/0x800 [] worker_thread+0x374/0x670 [] kthread+0x188/0x1c0 [] ret_from_fork+0x2b/0x50 [] ret_from_fork_asm+0x1a/0x30

中文

在Linux内核中，已解决以下漏洞：蓝牙：hci_codec：修复local_codecs的泄漏内容当控制器支持存储在local_codec列表中但从未释放元素的编解码器时，可以观察到以下内存泄漏：未引用对象0xffff88800221d840（大小32）：comm“kworker/u3:0”，pid 36，jiffies 4294898739（年龄127.060s）十六进制转储（前32个字节）：f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff。。。。。。。。。。！。。。。。00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 回溯：[]__kmalloc+0x47/0x120[]hci_codec_list_add.isra.0+0x2d/0x160[]hci_read_codec_capabilitys+0x183/0x270[]hci_read_supported_coodecs+0x1bb/0x2d0[]hci-read_local_decs_sync+0x3e/0x60 1b3>]hci_dev_open_sync+0x943/0x11e0[]hci_power_on+0x10d/0x3f0[]process_one_work+0x404/0x800[]worker_thread+0x374/0x670[<ffffff B3 0d9108>]kthread+0x188/0x1c0[]ret_from_fork+0x2b/0x50[]ret_from_fork_asm+0x1a/0x30

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52519

description

In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit The EHL (Elkhart Lake) based platforms provide a OOB (Out of band) service, which allows to wakup device when the system is in S5 (Soft-Off state). This OOB service can be enabled/disabled from BIOS settings. When enabled, the ISH device gets PME wake capability. To enable PME wakeup, driver also needs to enable ACPI GPE bit. On resume, BIOS will clear the wakeup bit. So driver need to re-enable it in resume function to keep the next wakeup capability. But this BIOS clearing of wakeup bit doesnt decrement internal OS GPE reference count, so this reenabling on every resume will cause reference count to overflow. So first disable and reenable ACPI GPE bit using acpi_disable_gpe().

中文

在Linux内核中，已解决以下漏洞：HID:intel ish HID:ipc:禁用并重新启用ACPI GPE位基于EHL（Elkhart Lake）的平台提供OOB（带外）服务，允许在系统处于S5（软关闭状态）时唤醒设备。可以通过BIOS设置启用/禁用此OOB服务。启用后，ISH设备将获得PME唤醒功能。要启用PME唤醒，驱动程序还需要启用ACPI GPE位。在恢复时，BIOS会清除唤醒位。因此，驱动程序需要在恢复功能中重新启用它，以保持下一次唤醒功能。但是BIOS清除唤醒位不会减少内部操作系统GPE引用计数，因此每次恢复时重新启用都会导致引用计数溢出。因此，首先使用ACPI_disable_GPE（）禁用并重新启用ACPI GPE位。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52520

description

In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting. As a side note, a very similar bug was fixed in commit 7295a996fdab (“platform/x86: dell-sysman: Fix reference leak”), so it seems that the bug was copied from that driver. Compile-tested only.

中文

在Linux内核中，以下漏洞已被解决：platform/x86:sthink-lmi:修复引用泄漏如果使用kset_find_obj（）发现重复的属性，则会返回对该属性的引用，需要使用kobject_put（）相应地处理该引用。将设置名称验证移到一个单独的函数中，以便进行此更改，而不必复制此设置的清理代码。顺便说一句，commit 7295a996fdab（“platform/x86:dell sysman:Fix reference leak”）中修复了一个非常相似的错误，因此该错误似乎是从该驱动程序中复制的。仅编译测试。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52521

description

In the Linux kernel, the following vulnerability has been resolved: bpf: Annotate bpf_long_memcpy with data_race syzbot reported a data race splat between two processes trying to update the same BPF map value via syscall on different CPUs: BUG: KCSAN: data-race in bpf_percpu_array_update / bpf_percpu_array_update write to 0xffffe8fffe7425d8 of 8 bytes by task 8257 on cpu 1: bpf_long_memcpy include/linux/bpf.h:428 [inline] bpf_obj_memcpy include/linux/bpf.h:441 [inline] copy_map_value_long include/linux/bpf.h:464 [inline] bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380 bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175 generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749 bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648 __sys_bpf+0x28a/0x780 __do_sys_bpf kernel/bpf/syscall.c:5241 [inline] __se_sys_bpf kernel/bpf/syscall.c:5239 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd write to 0xffffe8fffe7425d8 of 8 bytes by task 8268 on cpu 0: bpf_long_memcpy include/linux/bpf.h:428 [inline] bpf_obj_memcpy include/linux/bpf.h:441 [inline] copy_map_value_long include/linux/bpf.h:464 [inline] bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380 bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175 generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749 bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648 __sys_bpf+0x28a/0x780 __do_sys_bpf kernel/bpf/syscall.c:5241 [inline] __se_sys_bpf kernel/bpf/syscall.c:5239 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xfffffff000002788 The bpf_long_memcpy is used with 8-byte aligned pointers, power-of-8 size and forced to use long read/writes to try to atomically copy long counters. It is best-effort only and no barriers are here since it will race with concurrent updates from BPF programs. The bpf_long_memcpy() is called from bpf(2) syscall. Marco suggested that the best way to make this known to KCSAN would be to use data_race() annotation.

中文

在Linux内核中，已解决以下漏洞：bpf:Annotate bpf_long_memcpy with data_race syzbot报告了两个进程之间的数据争用，这两个进程试图通过不同cpu上的syscall更新相同的bpf映射值：BUG:KCSAN：cpu 1上的任务8257将bpf_percpu_array_update/bpf_percpu_array_update中的数据争用来写入8字节的0xffffe8fffe7425d8：bpf_lang_memcpy include/linux/bpf.h:428[inline]bpf_obj_memcpy include/linux/bpf.h:441[inline]copy_map_value_long include/linut/bpf.h:664[inline:bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap。c:380 bpf_map_update_value+0x190/0x370 kernel/bf/syscall。c:175 generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall。c:1749 bpf_map-do_bo_batch+0x2df/0x3d0 kernel/bpf/syscall。c:4648 __sys_bpf+0x28a/0x780 __do_sys_bpf kernel/bp/syscall。c:\5241[inline]__se_sys_bpf kernel/bbf/syscall.c：5239[内联]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall。c:5239 do_syscall_x64 arch/x86/entry/common。c:50[inline]do_syscall _64+0x41/0xc0 arch/x86/intry/common。c:80 entry_syscall_64_after_hwframe+0x63/0xcd通过cpu 0上的任务8268写入0xffffe8fffe7425d8字节的0xffffe8：bpf_long_memcpy include/linux/bpf.h:428[inline]bpf_obj_memcpy包含/linux/bpmf.h:441[inline】copy_map_value_long include/linux/bpf/h:446[inline]bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap。c:380 bpf_map_update_value+0x190/0x370 kernel/bf/syscall。c:175 generic_map_update_batch+0x3ae/0x4f0 kernel/bff/syscall。c:1749 bpf_map-do_batch+0x2df/0x3d0 kernel/bbf/syscall 1[内联]__se_sys_bpf kernel/bpf/syscall.c:5239[inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall。c:5239 do_syscall_x64 arch/x86/entry/common。c:50[inline]do_syscall _64+0x41/0xc0 arch/x86/intry/common.c:80 entry_syscall_64_after_hwframe+0x63/0xcd值已更改：0x0000000000000000->0xfffffffff000002788 bpf_long_memcpy与8字节对齐指针一起使用，大小为8的幂，并且被迫使用长读/写来尝试原子复制长计数器。这只是尽最大努力，没有任何障碍，因为它将与来自BPF程序的并发更新竞争。bpf_long_memcpy（）是从bpf（2）系统调用的。Marco建议，让KCSAN知道这一点的最好方法是使用data_race（）注释。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52522

description

In the Linux kernel, the following vulnerability has been resolved: net: fix possible store tearing in neigh_periodic_work() While looking at a related syzbot report involving neigh_periodic_work(), I found that I forgot to add an annotation when deleting an RCU protected item from a list. Readers use rcu_deference(*np), we need to use either rcu_assign_pointer() or WRITE_ONCE() on writer side to prevent store tearing. I use rcu_assign_pointer() to have lockdep support, this was the choice made in neigh_flush_dev().

中文

在Linux内核中，以下漏洞已得到解决：net:修复neigh_periodic_work（）中可能存在的存储撕裂问题。在查看涉及neigh_periodic_works（）的相关syzbot报告时，我发现从列表中删除受RCU保护的项时忘记添加注释。读卡器使用rcu_reference（*np），我们需要在写入端使用rcu_assign_pointer（）或WRITE_ONCE（）来防止存储撕裂。我使用rcu_ssign_pointr（）来支持lockdep，这是在neigh_flush_dev（）中做出的选择。

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52523

description

In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages sent from one TCP socket (s1) to actually egress from another TCP socket (s2): tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg tcp_bpf_send_verdict(s1) // __SK_REDIRECT case tcp_bpf_sendmsg_redir(s2) tcp_bpf_push_locked(s2) tcp_bpf_push(s2) tcp_rate_check_app_limited(s2) // expects tcp_sock tcp_sendmsg_locked(s2) // ditto There is a hard-coded assumption in the call-chain, that the egress socket (s2) is a TCP socket. However in commit 122e6c79efe1 (“sock_map: Update sock type checks for UDP”) we have enabled redirects to non-TCP sockets. This was done for the sake of BPF sk_skb programs. There was no indention to support sk_msg send-to-egress use case. As a result, attempts to send-to-egress through a non-TCP socket lead to a crash due to invalid downcast from sock to tcp_sock: BUG: kernel NULL pointer dereference, address: 000000000000002f … Call Trace: ? show_regs+0x60/0x70 ? __die+0x1f/0x70 ? page_fault_oops+0x80/0x160 ? do_user_addr_fault+0x2d7/0x800 ? rcu_is_watching+0x11/0x50 ? exc_page_fault+0x70/0x1c0 ? asm_exc_page_fault+0x27/0x30 ? tcp_tso_segs+0x14/0xa0 tcp_write_xmit+0x67/0xce0 __tcp_push_pending_frames+0x32/0xf0 tcp_push+0x107/0x140 tcp_sendmsg_locked+0x99f/0xbb0 tcp_bpf_push+0x19d/0x3a0 tcp_bpf_sendmsg_redir+0x55/0xd0 tcp_bpf_send_verdict+0x407/0x550 tcp_bpf_sendmsg+0x1a1/0x390 inet_sendmsg+0x6a/0x70 sock_sendmsg+0x9d/0xc0 ? sockfd_lookup_light+0x12/0x80 __sys_sendto+0x10e/0x160 ? syscall_enter_from_user_mode+0x20/0x60 ? __this_cpu_preempt_check+0x13/0x20 ? lockdep_hardirqs_on+0x82/0x110 __x64_sys_sendto+0x1f/0x30 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg program to prevent the crash. When attempted, user will receive an EACCES error from send/sendto/sendmsg() syscall.

中文

在Linux内核中，已解决以下漏洞：bpf，sockmap:Reject sk_msg egress重定向到非TCP套接字使用sockmap/SOCKHASH映射和sk_msg程序用户可以将从一个TCP套接字（s1）发送的消息引导到另一个TCP承口（s2）的实际出口：TCP_bpf_sendmsg（s1）//=sk_prot->sendmsg TCP_bf_send_verdict（s1）//__sk_REDIRECT case TCP_bpf.sendmsg_redir（s2）tcp_bpf_push_locked（s2）tcp_bpf_push（s2）tcp_rate_check_app_limited（s2。然而，在commit 122e6c79efe1（“sock_map:Update sock type checks for UDP”）中，我们启用了到非TCP套接字的重定向。这样做是为了BPF sk_skb程序。没有标识来支持sk_msg发送到出口用例。因此，尝试通过非TCP套接字发送到egress会导致崩溃，原因是从sock到TCP_sock:BUG:kernel NULL指针取消引用无效，地址：000000000000002f。。。呼叫跟踪：＜TASK＞？show_regs+0x60/0x70__骰子+0x1f/0x70？page_fault_ops+0x80/0x160？do_user_addr_fail+0x2d7/0x800？rc_is_watching+0x11/0x50？exc_page_fault+0x70/0x1c0？asm_exc_page_fault+0x27/0x30？tcp_tso_segs+0x14/0xa0 tcp_write_xmit+0x67/0xce0 __tcp_push_pending_frames+0x32/0xf0 tcp_push+0x107/0x140 tcp_sendmsg_locked+0x99f/0xbb0 tcp_bpf_push+0x19d/0x3a0 tcp_bpf_sendmsg_redir+0x55/0xd0 tcp_bff_send_verdict+0x407/0x550 tcp_bpf_fsendmsg+0x1a1/0x390 inet_sendmsg+0x6a/0x70 sock_sendmsg+0.x9d/0xc0？sockfd_lookup_light+0x12/0x80__sys_sendto+0x10e/0x160？syscall_enter_from_user_mode+0x20/0x60__this_cpu_premept_check+0x13/0x20？lockdep_hardirqs_on+0x82/0x110__x64_sys_sendto+0x1f/0x30 do_syscall_64+0x38/0x90 entry_syscall_64_after_hwframe+0x63/0xcd拒绝从BPF sk_msg程序中选择非TCP套接字作为重定向目标以防止崩溃。尝试时，用户将收到来自send/sendto/sendmsg（）系统调用的EACCES错误。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52524

description

In the Linux kernel, the following vulnerability has been resolved: net: nfc: llcp: Add lock when modifying device list The device list needs its associated lock held when modifying it, or the list could become corrupted, as syzbot discovered.

中文

在Linux内核中，已解决以下漏洞：net:nfc:llcp:在修改设备列表时添加锁设备列表在修改时需要持有其关联的锁，否则列表可能会损坏，正如syzbot发现的那样。

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52525

description

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet Only skip the code path trying to access the rfc1042 headers when the buffer is too small, so the driver can still process packets without rfc1042 headers.

中文

在Linux内核中，已经解决了以下漏洞：wifi:mwifiex:修复了mwifiex_process_rx_packet中的oob检查条件当缓冲区太小时，只跳过试图访问rfc1042标头的代码路径，因此驱动程序仍然可以处理没有rfc1042的标头的数据包。

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52526

description

In the Linux kernel, the following vulnerability has been resolved: erofs: fix memory leak of LZMA global compressed deduplication When stressing microLZMA EROFS images with the new global compressed deduplication feature enabled (-Ededupe), I found some short-lived temporary pages werent properly released, which could slowly cause unexpected OOMs hours later. Lets fix it now (LZ4 and DEFLATE dont have this issue.)

中文

在Linux内核中，以下漏洞已被解决：erofs:修复LZMA全局压缩重复数据消除的内存泄漏当在启用新的全局压缩重复删除功能（-Edepup）的情况下对microLZMA erofs映像施加压力时，我发现一些短暂的临时页面没有正确发布，这可能会在数小时后慢慢导致意外的OOM。让我们现在修复它（LZ4和DEFLATE没有这个问题。）

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52527

description

In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen in length is a problem when the packet is partially filled (e.g. something like send(MSG_MORE) happened previously) when appending to an IPv4 or IPv6 packet as we dont want to repeat the transport header or account for it twice. This can happen under some circumstances, such as splicing into an L2TP socket. The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 that occurs when MSG_SPLICE_PAGES is used to append more data to an already partially occupied skbuff. The warning occurs when copy is larger than the amount of data in the message iterator. This is because the requested length includes the transport header length when it shouldnt. This can be triggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, …); // ::1 connect(sfd, …); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024); Fix this by only adding transhdrlen into the length if the write queue is empty in l2tp_ip6_sendmsg(), analogously to how UDP does things. l2tp_ip_sendmsg() looks like it wont suffer from this problem as it builds the UDP packet itself.

中文

在Linux内核中，以下漏洞已得到解决：ipv4，ipv6：修复__ip｛，6｝_append_data（）中transdrlen的处理。当数据包被部分填充时（例如，以前发生过类似send（MSG_MORE）的情况），在附加到ipv4或ipv6数据包时会出现问题，因为我们不想重复传输标头或对其进行两次说明。这种情况在某些情况下可能发生，例如拼接到L2TP套接字中。观察到的症状是__ip6_append_data（）中的警告：警告：CPU:1 PID:5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800，当MSG_SPLICE_PAGES用于将更多数据附加到已部分占用的skbuff时会发生这种情况。当副本大于消息迭代器中的数据量时，会出现警告。这是因为请求的长度包括传输标头长度，而不应该包括。这可以通过以下方式触发，例如：sfd=套接字（AF_INET6、SOCK_DGRAM、IPPROTO_L2TP）；绑定（sfd，…）；//：：1个连接（sfd，…）；//：：1端口7发送（sfd，buffer，4100，MSG_MORE）；sendfile（sfd，dfd，NULL，1024）；如果l2tp_ip6_sendmsg（）中的写入队列为空，只需将transdrlen添加到长度中即可解决此问题，类似于UDP的操作方式。l2tp_ip_sendmsg（）看起来不会遇到这个问题，因为它自己构建UDP数据包。

cvss epss percentile
None 0.04% 10.69%

references

CVE-2023-52528

description

In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg syzbot reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable —-buf.i87@smsc75xx_bind created at: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer). In this case, buf is not properly filled. This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads less bytes than requested.

中文

在Linux内核中，已解决以下漏洞：net:usb:smsc75xx:修复__smsc75xx_read_reg中的uninit值访问问题syzbot报告了以下unimit值访问问题：=========================================BUG:KMSAN:smsc75xx中的unimit值_wait_ready drivers/net/usb/smsc75xxx.c:975[inline]BUG:KMSAN:smsc75xx_bind+0x5cc9/0x11e0 drivers/net-usb/smsc75xxx.c:1482 CPU:0 PID:8696 Comm:kworker/0:3未受污染5.8.0-rc5-yzkaller#0硬件名称：谷歌谷歌计算引擎/谷歌计算引擎，BIOS谷歌2011年1月1日工作队列：usb_hub_wq hub_event调用跟踪：__dump_stack lib/dump_stack.c:77[inline]dump_stack+0x21c/0x280 lib/dump.stack.c:118 KMSAN_report+0xf7/0x1e0 mm/KMSAN/KMSAN_report.c:121 __msan_warning+0x58/0xa0 mm/KMSAN/KMSAN_instr.c:215 smsc75xx_wait_ready drivers/net/usb/sm sc75xx.c:975[内联]smsc75xx_bind+0x5cc9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net-usb/usbnet.c:11737 usb_probe_interface+0xece/0x1550 drivers/usb/core/ddriver.c:374 really_probe+0xf20/0x20b0 drivers/base/ddc:529 driver_be_device+0x293/0x390 drivers/bbase/ddc:701 __device_attach_driver+0x63f/0x830 drivers/basic/ddc:807 bus_for_each_drv 0+0x2ca/0x3f0驱动程序/base/dbus。c:431 __device_attach+0x4e2/0x7f0驱动器/base/ddc:873 device_initial_probe+0x4a/0x60驱动程序/bbase/ddc:920 bus_probe_device+0x177/0x3d0驱动程序/base/dbus。c:\491 device_add+0x3b0e/0x40d0驱动器/base/core。c:2680 usb_set_configuration+0x380f/0x3f10驱动程序/usb/core/message。c:2032 usb_generalize_driver_be+0x138/0x300驱动程序/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/ddriver。c:272 really_probe+0xf20/0x20b0 drivers/base/ddc:529 driver_probe_device=0x293/0x390 drivers/bbase/ddc:701 __device_attach_driver+0x63f/0x830 drivers/basic/ddc:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus。c:431__device_attach+0x4e2/0x7f0 drivers/base/ddc:873 device_initial_probe+0x4a/0x60 drivers/bbase/ddc:920 bus_probe_device+0x177/0x3d0 drivers-base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/ubs/core/hube.c:5208[inline]hub_port-connect_change drivers/ubus/core/hhub.c：5348[inline]port_event drivers/usb/core/hub。c:5494[inline]hub_event+0x5e7b/0x8a70 drivers/ubs/core/hube。c:5576 process_one_work+0x1688/0x2140 kernel/workqueue。c:2269 worker_thread+0x10bc/0x2730 kernel/wworkqueue。c:\2415 kthread+0x551/0x590 kernel/khread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64。S:293本地变量—-buf.i87@smsc75xx_bind创建位置：__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83[inline]smsc75xxx_wait_ready drivers/net-usb/smsc75xx。c:968[inline]smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx。c:\1482 __smsc75 xx_read-reg drivers/not/usb/smsc 75xx。c:83[iinline]smsc 75xx_wait_ady drivers/net/ubs/smsc:968[inline]smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482此问题是由于usbnet_read_cmd（）读取的字节数少于请求的字节数（再现器中为零字节）。在这种情况下，buf没有正确填充。如果usbnet_read_cmd（）读取的字节数少于请求的字节数，则此补丁通过返回-ENODATA来修复此问题。

cvss epss percentile
None 0.04% 10.69%

references

CVE-2023-52529

description

In the Linux kernel, the following vulnerability has been resolved: HID: sony: Fix a potential memory leak in sony_probe() If an error occurs after a successful usb_alloc_urb() call, usb_free_urb() should be called.

中文

在Linux内核中，已解决以下漏洞：HID:sony：修复sony_probe（）中潜在的内存泄漏如果在成功调用usb_alloc_urb（）后发生错误，则应调用usb_free_urb（）。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52530

description

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential key use-after-free When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesnt happen since its only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add().

中文

在Linux内核中，以下漏洞已被解决：wifi：mac80211:修复释放后的潜在密钥使用当ieee80211_gtk_rekey_add（）调用ieee80211-key_link（），但由于KRACK保护（重新安装相同的密钥）而返回0时，ieee80211 _gtk_rekey_add（。这种情况通常不会发生，因为它只由iwlwifi在WoWLAN rekey卸载的情况下调用，该卸载有自己的KRACK保护，但最好通过返回错误代码并仅在cfg80211边界上将其转换为成功来修复，将错误留给ieee80211_gtk_rekey_add（）的坏调用方。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52531

description

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory corruption issue A few lines above, space is kzalloc()ed for: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate) mvm->nvm_data is a struct iwl_nvm_data, so it is fine. At the end of this structure, there is the channels flex array. Each element is of type struct ieee80211_channel. So only 1 element is allocated in this array. When doing: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the channels flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1); because of the “(u8 *)” cast, we add only 1 to the address of the beginning of the flex array. It is likely that we want point at the struct ieee80211_rate allocated just after. Remove the spurious casting so that the pointer arithmetic works as expected.

中文

在Linux内核中，以下漏洞已被解决：wifi:iwlwifi:mvm：修复内存损坏问题上面几行，空格为kzalloc（）ed表示：sizeof（struct iwl_nvm_data）+sizeof（struct ieee80211_channel）+sizef（struct ieee80211-rate）mvm->nvm_data是一个struct iwl_nvm_data，所以它很好。在这个结构的末端，有通道柔性阵列。每个元素的类型都是structure ieee80211_channel。所以在这个数组中只分配了一个元素。执行时：mvm->nvm_data->bands[0]。channels=mvm->nvm_data->channels；我们指向通道弯曲阵列的第一个元素。所以这很好。但是，当执行以下操作时：mvm->nvm_data->bands[0]。比特率=（void*）（（u8*）mvm->nvm_data->channels+1）；由于“（u8*）”强制转换，我们只在flex数组开头的地址上加1。很可能我们想要指向紧接着分配的结构ieee80211_rate。删除伪强制转换，以便指针算术按预期工作。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52532

description

In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix TX CQE error handling For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting corrupted packets, so replace the WARN_ONCE to ratelimited error logging.

中文

在Linux内核中，以下漏洞已被解决：net:mana:修复TX CQE错误处理对于未知的TX CQE故障类型（可能来自较新的硬件），仍然释放SKB、更新队列尾部等，否则计费将是错误的。此外，注入损坏的数据包可能会触发TX错误，因此请将WARN_ONCE替换为速率受限的错误日志记录。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52559

description

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid memory allocation in iommu_suspend() The iommu_suspend() syscore suspend callback is invoked with IRQ disabled. Allocating memory with the GFP_KERNEL flag may re-enable IRQs during the suspend callback, which can cause intermittent suspend/hibernation problems with the following kernel traces: Calling iommu_suspend+0x0/0x1d0 ————[ cut here ]———— WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0 … CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1 RIP: 0010:ktime_get+0x9b/0xb0 … Call Trace: tick_sched_timer+0x22/0x90 ? __pfx_tick_sched_timer+0x10/0x10 __hrtimer_run_queues+0x111/0x2b0 hrtimer_interrupt+0xfa/0x230 __sysvec_apic_timer_interrupt+0x63/0x140 sysvec_apic_timer_interrupt+0x7b/0xa0 asm_sysvec_apic_timer_interrupt+0x1f/0x30 … ————[ cut here ]———— Interrupts enabled after iommu_suspend+0x0/0x1d0 WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270 CPU: 0 PID: 27420 Comm: rtcwake Tainted: G U W E 6.3-intel #r1 RIP: 0010:syscore_suspend+0x147/0x270 … Call Trace: hibernation_snapshot+0x25b/0x670 hibernate+0xcd/0x390 state_store+0xcf/0xe0 kobj_attr_store+0x13/0x30 sysfs_kf_write+0x3f/0x50 kernfs_fop_write_iter+0x128/0x200 vfs_write+0x1fd/0x3c0 ksys_write+0x6f/0xf0 __x64_sys_write+0x1d/0x30 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Given that only 4 words memory is needed, avoid the memory allocation in iommu_suspend().

中文

在Linux内核中，已解决以下漏洞：iommu/vt-d:避免iommu _suspend（）中的内存分配在禁用IRQ的情况下调用iommu _suspend）syscore挂起回调。使用GFP_KERNEL标志分配内存可能会在挂起回调期间重新启用IRQ，这可能会导致以下内核跟踪的间歇性挂起/休眠问题：调用iommu_suspend+0x0/0x1d0—————-[此处剪切]—————-警告：CPU:0 PID:15 at KERNEL/time/timekeeping。c:868 ktime_get+0x9b/0xb0。。。CPU:0 PID:15通信：rcu_presept受污染：G U E 6.3-intel#r1 RIP:0010：ktime_get+0x9b/0xb0。。。调用跟踪：＜IRQ＞tick_sched_timer+0x22/0x90__pfx_tick_sched_timer+0x10/0x10 __hrtimer_run_queues+0x111/0x2b0 hrtimer_interrupt+0xfa/0x230 __sysvec_apic_timer_interrupt+0x63/0x140 sysvec_apict_timer_interrupt+0x7b/0xa0asm_sysvec_apic_timer_nterrupt+0x1f/0x30————[此处剪切]—————iommu_suspend+0x0/0x1d0之后启用中断警告：CPU:0 PID:27420在驱动程序/base/syscore.c:68 syscore_suspend+0x147/0x270 CPU:0 PID：27420通信：rtcwake Tained:G U W E 6.3-intel#r1 RIP:0010：syscore_suppend+0x147/0x270。。。调用跟踪：hibernation_snapshot+0x25b/0x670 hibernate+0xcd/0x390 state_store+0xcf/0xe0 kobj_attr_store+0x13/0x30 sysfs_kf_write+0x3f/0x50 kernfs_fop_write_iter+0x128/0x200 vfs_write+0x1fd/0x3c0 ksys_write+0x6f/0xf0 __x64_sys_write+0x1d/0x30 do_syscall_64+0x3b/0x90 entry_syscall_64_after_hwframe+0x72/0xdc如果只需要4个字的内存，请避免内存分配在iommu_suspend（）中。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52560

description

In the Linux kernel, the following vulnerability has been resolved: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions() When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected. Since commit 9f86d624292c (“mm/damon/vaddr-test: remove unnecessary variables”), the damon_destroy_ctx() is removed, but still call damon_new_target() and damon_new_region(), the damon_region which is allocated by kmem_cache_alloc() in damon_new_region() and the damon_target which is allocated by kmalloc in damon_new_target() are not freed. And the damon_region which is allocated in damon_new_region() in damon_set_regions() is also not freed. So use damon_destroy_target to free all the damon_regions and damon_target. unreferenced object 0xffff888107c9a940 (size 64): comm “kunit_try_catch”, pid 1069, jiffies 4294670592 (age 732.761s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b …………kkkk 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `…………… backtrace: [] kmalloc_trace+0x27/0xa0 [] damon_new_target+0x3f/0x1b0 [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 [] damon_test_apply_three_regions1+0x21e/0x260 [] kunit_generic_run_threadfn_adapter+0x4a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff8881079cc740 (size 56): comm “kunit_try_catch”, pid 1069, jiffies 4294670592 (age 732.761s) hex dump (first 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ……………. 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk….kkkk backtrace: [] damon_new_region+0x22/0x1c0 [] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0 [] damon_test_apply_three_regions1+0x21e/0x260 [] kunit_generic_run_threadfn_adapter+0x4a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff888107c9ac40 (size 64): comm “kunit_try_catch”, pid 1071, jiffies 4294670595 (age 732.843s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b …………kkkk a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ……..x.v….. backtrace: [] kmalloc_trace+0x27/0xa0 [] damon_new_target+0x3f/0x1b0 [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 [] damon_test_apply_three_regions2+0x21e/0x260 [] kunit_generic_run_threadfn_adapter+0x4a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff8881079ccc80 (size 56): comm “kunit_try_catch”, pid 1071, jiffies 4294670595 (age 732.843s) hex dump (first 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ……………. 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk….kkkk backtrace: [] damon_new_region+0x22/0x1c0 [] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0 [] damon_test_apply_three_regions2+0x21e/0x260 [] kunit_generic_run_threadfn_adapter+0x4a/0x90 [] kthread+0x2b6/0x380 [] ret_from_fork+0x2d/0x70 [<ffff —truncated—

中文

在Linux内核中，已解决以下漏洞：mm/damon/vadr test:修复damon_do_test_apply_three_regions（）中的内存泄漏。当CONFIG_damon_vaddr_KUNIT_test=y并使CONFIG_DEBUG_KMEMLEAK=y和CONFIG_DEBUG_KMEMLEK_AUTO_SCAN=y时，检测到以下内存泄漏。由于commit 9f86d624292c（“mm/damon/vadr test:remove unnecessary variables”），删除了damon_deroy_ctx（），但仍调用damon_new_target（）和damon_nev_region（），由kmem_cache_alloc（）在damon_new-region（）中分配的damon_reregion和由kmalloc在damon_e_target中分配的damon_etarget（）没有释放。并且在damon_set_regions（）中的damon_new_region（）中分配的damon_reregion也没有被释放。因此，使用damon_desty_target来释放所有的damon_reregions和damon_target。未引用的对象0xffff888107c9a940（大小64）：comm“kunit_try_catch”，pid 1069，jiffies 4294670592（年龄732.761s）十六进制转储（前32字节）：00 00 00 00 06 00 00 00 6b 6b。。。。。。。。。。。。kkkk 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 88 ff ff `。。。。。。。。。。。。。。。回溯：[<ffffffff 817e0167>]kmalloc_trace+0x27/0xa0[<ffff ffff 819c11cf>]damon_n_target+0x3f/0x1b0[<ff ffffff 819c7d55>]damo_do_test_apply_thread_region.constprop.0+0x95/0x3e0[<ffiffff 819c82be>]damn_test_apply_Thread_reregions1+0x21e/0x260[<ffFFff 829fce6a>]kunit_generic_run_threadfn_adapter+0x4a/0x90 ffff 81237cf6>]k线程+0x2b6/0x380[<ffffff 81097add>]ret_from_fork+0x2d/0x70[]ret_from-fork_asm+0x11/0x20未引用对象0xffffff8881079cc740（大小56）：comm“kunit_try_catch”，pid 1069，jiffies 4294670592（年龄732.761s）十六进制转储（前32个字节）：05 00 00 00 00 0 00 00 00 14 00 00 00 000 00 00 00。。。。。。。。。。。。。。。。6b6b6b6b 6b 6b6b 00 00 00 00 6b 6b6B 6b kkkkkk。。。。kkkk回溯：[<ffffffff 819bc492>]damon_n_region+0x22/0x1c0[<ffff ffff 819c7d91>]dama_to_test_apply_three_regions.constprop.0+0xd1/0x3e0[<ff fffffffff 819c82be>]damon_to_test_apply_tthree_regions1+0x21e/0x260[<ffiffff 829fce6a>]kunit_generic_run_threadfn_adapter+0x4a/0x90[<ffoffff 81237cf6>]kthread+0x2b6/0x380[<ffffffff 81097add>]ret_from_fork+0x2d/0x70[<ffff ffff 81003791>]ret_from_fork_asm+0x11/0x20未引用对象0xffff888107c9ac40（大小64）：comm“kunit_try_catch”，pid 1071，jiffies 4294670595（年龄732.843s）十六进制转储（前32个字节）：00 00 00 00 06 00 00 00 6b 6b。。。。。。。。。。。。kkkk a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ffff。。。。。。。。x.v…..回溯：[<ffffffffff 817e0167>]kmalloc_trace+0x27/0xa0[<ffff ffffff 819c11cf>]damon_new_target+0x3f/0x1b0[<ffFFffff 819c7d55>]dama_do_test_apply_thread_region.constprop:0+0x95/0x3e0[<ffFF 819c851e>]damo_test_apply_Thread_reregions2+0x21e/0x260[<ffiffff 829fce6a>]kunit_generic_run_threadfn_adapter+0x4a/0x90[<ffffffff 81237cf6>]k线程+0x2b6/0x380[<ffffff 81097add>]ret_from_fork+0x2d/0x70[]ret_from-fork_asm+0x11/0x20未引用对象0xffffff8881079ccc80（大小56）：comm“kunit_try_catch”，pid 1071，jiffies 4294670595（年龄732.843s）十六进制转储（前32个字节）：05 00 00 00 00 0 00 00 00 14 00 00 00 000 00 00 00。。。。。。。。。。。。。。。。6b6b6b6b 6b 6b6b 00 00 00 00 6b 6b6B 6b kkkkkk。。。。kkkk回溯：[<ffffffff 819bc492>]damon_n_region+0x22/0x1c0[<ffff ffff 819c7d91>]damo_do_test_apply_three_regions.constprop.0+0xd1/0x3e0[<ff fffffffff 819c851e>]damn_test_apply_three_region2+0x21e/0x260[<ffFFffff 829fce6a>]kunit_generic_run_threadfn_adapter+0x4a/0x90[<ffiffff 81237cf6>]kthread+0x2b6/0x380[<ffffffff 81097add>]ret_from_fork+0x2d/0x70[<ffff—截断—

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52561

description

In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved Adding a reserved memory region for the framebuffer memory (the splash memory region set up by the bootloader). It fixes a kernel panic (arm-smmu: Unhandled context fault at this particular memory region) reported on DB845c running v5.10.y.

中文

在Linux内核中，已解决以下漏洞：arm64:dts:qcom:sdm845-db845c:将cont启动内存区域标记为保留添加帧缓冲区内存的保留内存区域（引导加载程序设置的启动内存区域）。它修复了运行v5.10.y的DB845c上报告的内核死机（arm-smmu：此特定内存区域的未处理上下文错误）。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52562

description

In the Linux kernel, the following vulnerability has been resolved: mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy() After the commit in Fixes:, if a module that created a slab cache does not release all of its allocated objects before destroying the cache (at rmmod time), we might end up releasing the kmem_cache object without removing it from the slab_caches list thus corrupting the list as kmem_cache_destroy() ignores the return value from shutdown_cache(), which in turn never removes the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails to release all of the caches slabs. This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y as after that ill release the system will immediately trip on list_add, or list_del, assertions similar to the one shown below as soon as another kmem_cache gets created, or destroyed: [ 1041.213632] list_del corruption. next->prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268) [ 1041.219165] ————[ cut here ]———— [ 1041.221517] kernel BUG at lib/list_debug.c:62! [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0 Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y, is to set slub_debug to poison the released objects and then just run cat /proc/slabinfo after removing the module that leaks slab objects, in which case the kernel will panic: [ 50.954843] general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 [#1] PREEMPT SMP PTI [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 50.966808] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0 This patch fixes this issue by properly checking shutdown_cache()s return value before taking the kmem_cache_release() branch.

中文

在Linux内核中，已解决以下漏洞：mm/slab_common:fix slab_caches list corruption after kmem_cache_destroy（）在Fixes:中提交之后，如果创建slab缓存的模块在销毁缓存之前（在rmmod时间）没有释放其所有分配的对象，我们最终可能会在不将kmem_cache对象从slab_caches列表中删除的情况下释放它，从而损坏列表，因为kmem_cachi_destroy（）忽略了shutdown_cache（）的返回值，而shutdown（）则永远不会从slabs_list中删除kmem_cche对象，以防__kmem_cache_shutdown）无法释放所有缓存板。这在使用CONFIG_DEBUG_LIST=y构建的内核上很容易观察到，因为在该错误发布之后，一旦创建或销毁了另一个kmem_cache，系统将立即触发LIST_add或LIST_del断言，类似于下面所示的断言：[10421.23632]LIST_del corruption。next->prev应该是ffff89f596fb5768，但是52f1e5016aeee75d。（next=ffff89f595a1b268）[10421.29165]—————[剪切此处]—————-[10412.2517]lib/list_debug的内核BUG。c:62！[10411.223452]无效操作码：0000[#1]PREEMPT SMP PTI[10411.225408]CPU:2 PID:1852 Comm:rmmod Kdump:loaded Tained:G B W OE 6.5.0#15[10411.228244]硬件名称：QEMU Standard PC（Q35+ICH92009），BIOS edk2-0230552-4-3.fc37 05/24/2023[104122122]RIP:0010:__list_del_entry_valid+0xae/0xb0在CONFIG_SLUB=y的内核中触发此问题的另一种快速方法，是将slub_debug设置为毒害已释放的对象，然后在删除泄漏slab对象的模块后仅运行cat/proc/slabinfo，在这种情况下，内核将死机：[50.954843]一般保护故障，可能是针对非规范地址0xa56b6b6b6b8b:0000[#1]PREEMPT SMP PTI[50.961545]CPU:2 PID:1495 Comm:cat Kdump:loaded Tained:G B W OE 6.5.0#15[50.966808]硬件名称：QEMU标准PC（Q35+ICH92009），BIOS edk2-202305244-3.fc37 05/24/2023[50972663]RIP:0010：get_slabinfo+0x42/0xf0此补丁通过在执行kmem_cache_release（）分支之前正确检查shutdown_cache（）的返回值来修复此问题。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52563

description

In the Linux kernel, the following vulnerability has been resolved: drm/meson: fix memory leak on ->hpd_notify callback The EDID returned by drm_bridge_get_edid() needs to be freed.

中文

在Linux内核中，已解决以下漏洞：drm/meson:修复->hpd_notify回调上的内存泄漏需要释放drm_bridge_get_EDID（）返回的EDID。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52564

description

In the Linux kernel, the following vulnerability has been resolved: Revert “tty: n_gsm: fix UAF in gsm_cleanup_mux” This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239. The commit above is reverted as it did not solve the original issue. gsm_cleanup_mux() tries to free up the virtual ttys by calling gsm_dlci_release() for each available DLCI. There, dlci_put() is called to decrease the reference counter for the DLCI via tty_port_put() which finally calls gsm_dlci_free(). This already clears the pointer which is being checked in gsm_cleanup_mux() before calling gsm_dlci_release(). Therefore, it is not necessary to clear this pointer in gsm_cleanup_mux() as done in the reverted commit. The commit introduces a null pointer dereference: ? __die+0x1f/0x70 ? page_fault_oops+0x156/0x420 ? search_exception_tables+0x37/0x50 ? fixup_exception+0x21/0x310 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x26/0x30 ? tty_port_put+0x19/0xa0 gsmtty_cleanup+0x29/0x80 [n_gsm] release_one_tty+0x37/0xe0 process_one_work+0x1e6/0x3e0 worker_thread+0x4c/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 The actual issue is that nothing guards dlci_put() from being called multiple times while the tty driver was triggered but did not yet finished calling gsm_dlci_free().

中文

在Linux内核中，已解决以下漏洞：Revert“tty:n_gsm:fix UAF In gsm_cleanup_mux”这将还原commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239。上面的提交被恢复，因为它没有解决原始问题。gsm_cleanup_mux（）试图通过为每个可用dlci调用gsm_dlci_release（）来释放虚拟tty。在那里，通过tty_port_put（）调用dlci_put（。这已经清除了在调用gsm_dlci_release（）之前在gsm_cleanup_mux（）中检查的指针。因此，没有必要像恢复提交中那样在gsm_cleanup_mux（）中清除此指针。提交引入了一个空指针取消引用：＜TASK＞__骰子+0x1f/0x70？page_fault_ops+0x156/0x420？search_exception_tables+0x37/0x50？fixup_exception+0x21/0x310？exc_page_fault+0x69/0x150？asm_exc_page_fault+0x26/0x30？tty_port_put+0x19/0xa0 gsmtty_cleanup+0x29/0x80[n.gsm]release_one_tty+0x37/0xe0 process_one_work+0x1e6/0x3e0 worker_thread+0x4c/0x3d0__pfx_worker_thread+0x10/0x10 k thread+0xe1/0x110__pfx_k线程+0x10/0x10 ret_from_fork+0x2f/0x50__pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30实际问题是，当tty驱动程序被触发但尚未完成对gsm_dlci_free（）的调用时，没有任何东西可以保护dlci_put（）不被多次调用。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52565

description

In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix OOB read If the index provided by the user is bigger than the mask size, we might do an out of bound read.

中文

在Linux内核中，已解决以下漏洞：media:uvcvideo:Fix OOB read如果用户提供的索引大于掩码大小，我们可能会进行越界读取。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52566

description

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential use after free in nilfs_gccache_submit_read_data() In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page. NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly. [konishi.ryusuke@gmail.com: NOTE added to the commit log]

中文

在Linux内核中，已解决以下漏洞：nilf2:修复nilfs_gcache_submit_read_data（）中释放后的潜在使用。在nilfs_ccache_submit _read_data.（）中，当对nilfs_dt_translate（）的调用失败时，会调用brelse（bh）来删除bh的引用计数。如果引用计数达到0并且其所有者页面被解锁，则bh可能被释放。然而，bh->b_page被取消引用以将页面放在其后，这可能会导致释放后使用错误。此修补程序在解锁并放置页面后移动释放操作。注：有问题的函数仅在GC中调用，并且与当前的userland工具相结合，该函数中不会使用DAT进行地址转换，因此不会执行导致此问题的代码路径。但是，可以通过有意修改userland GC库或直接调用GC ioctl来运行该代码路径。[konishi.ryusuke@gmail.com：注意添加到提交日志]

cvss epss percentile
None 0.04% 10.69%

references

CVE-2023-52567

description

In the Linux kernel, the following vulnerability has been resolved: serial: 8250_port: Check IRQ data before use In case the leaf driver wants to use IRQ polling (irq = 0) and IIR register shows that an interrupt happened in the 8250 hardware the IRQ data can be NULL. In such a case we need to skip the wake event as we came to this path from the timer interrupt and quite likely system is already awake. Without this fix we have got an Oops: serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A … BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:serial8250_handle_irq+0x7c/0x240 Call Trace: ? serial8250_handle_irq+0x7c/0x240 ? __pfx_serial8250_timeout+0x10/0x10

中文

在Linux内核中，已解决以下漏洞：serial:8250_port:使用前检查IRQ数据如果叶驱动程序想要使用IRQ轮询（IRQ=0），并且IIR寄存器显示8250硬件中发生中断，则IRQ数据可能为NULL。在这种情况下，我们需要跳过唤醒事件，因为我们从定时器中断到达这条路径，很可能系统已经唤醒了。如果没有此修复程序，我们在I/O 0x3f8（irq=0，base_baud=115200）处得到一个Oops:serial8250:ttyS0是16550A。。。BUG：内核NULL指针取消引用，地址：0000000000000010 RIP:0010：serial8250_handle_irq+0x7c/0x240调用跟踪：？serial8250_handle_irq+0x7c/0x240__pfx_serial8250_timeout+0x10/0x10

cvss epss percentile
None 0.04% 10.69%

references

CVE-2023-52568

description

In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an enclave and set secs.epc_page to NULL. The SECS page is used for EAUG and ELDU in the SGX page fault handler. However, the NULL check for secs.epc_page is only done for ELDU, not EAUG before being used. Fix this by doing the same NULL check and reloading of the SECS page as needed for both EAUG and ELDU. The SECS page holds global enclave metadata. It can only be reclaimed when there are no other enclave pages remaining. At that point, virtually nothing can be done with the enclave until the SECS page is paged back in. An enclave can not run nor generate page faults without a resident SECS page. But it is still possible for a #PF for a non-SECS page to race with paging out the SECS page: when the last resident non-SECS page A triggers a #PF in a non-resident page B, and then page A and the SECS both are paged out before the #PF on B is handled. Hitting this bug requires that race triggered with a #PF for EAUG. Following is a trace when it happens. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:sgx_encl_eaug_page+0xc7/0x210 Call Trace: ? __kmem_cache_alloc_node+0x16a/0x440 ? xa_load+0x6e/0xa0 sgx_vma_fault+0x119/0x230 __do_fault+0x36/0x140 do_fault+0x12f/0x400 __handle_mm_fault+0x728/0x1110 handle_mm_fault+0x105/0x310 do_user_addr_fault+0x1ee/0x750 ? __this_cpu_preempt_check+0x13/0x20 exc_page_fault+0x76/0x180 asm_exc_page_fault+0x27/0x30

中文

在Linux内核中，已解决以下漏洞：x86/sgx:解决EAUG竞赛的SECS回收与页面错误sgx EPC回收器（ksgxd）可能会回收某个飞地的SECS EPC页面，并将SECS.EPC_page设置为NULL。SECS页面用于SGX页面故障处理程序中的EAUG和ELDU。但是，secs.epc_page的NULL检查仅对ELDU执行，而不是在使用之前对EAUG执行。通过对EAUG和ELDU执行相同的NULL检查并根据需要重新加载SECS页面来修复此问题。SECS页面包含全局包围区元数据。只有当没有其他飞地页面时，才能回收它。在这一点上，在SECS页面被分页回之前，几乎无法对飞地执行任何操作。如果没有驻留的SECS页面，飞地就无法运行或生成页面错误。但是，非SECS页面的#PF仍然有可能与寻呼出SECS页面竞争：当最后一个驻留的非SECS页a触发非驻留页B中的#PF时，然后在处理B上的#PF之前，页a和SECS都被寻呼出。要想解决这个bug，需要使用#PF为EAUG触发比赛。下面是它发生时的痕迹。BUG：内核NULL指针取消引用，地址：0000000000000000 RIP:0010：sgx_encl_eaug_page+0xc7/0x210调用跟踪：__kmem_cache_alloc_node+0x16a/0x440？xa_load+0x6e/0xa0 sgx_vma_fault+0x119/0x230 __do_fault+0x36/0x140 do_fault+0x12f/0x400 __handle_mm_fault+0x728/0x1110 handle_mm_fault+0x105/0x310 do_user_addr_ault+0x1ee/0x750__this_cpu_premept_check+0x13/0x20 exc_page_fault+0x76/0x180 asm_exc_page_fault+0x27/0x30

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52569

description

In the Linux kernel, the following vulnerability has been resolved: btrfs: remove BUG() after failure to insert delayed dir index item Instead of calling BUG() when we fail to insert a delayed dir index item into the delayed nodes tree, we can just release all the resources we have allocated/acquired before and return the error to the caller. This is fine because all existing call chains undo anything they have done before calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending snapshots in the transaction commit path). So remove the BUG() call and do proper error handling. This relates to a syzbot report linked below, but does not fix it because it only prevents hitting a BUG(), it does not fix the issue where somehow we attempt to use twice the same index number for different index items.

中文

在Linux内核中，以下漏洞已被解决：btrfs:remove BUG（）after failed to insert delayed dir index item当我们未能将延迟的dir索引项插入到延迟节点树中时，我们可以不调用BUG（（），而是释放之前分配/获取的所有资源，并将错误返回给调用方。这很好，因为所有现有的调用链都会撤消它们在调用btrfs_insert_delayered_dir_index（）或BUG_ON（在事务提交路径中创建挂起的快照时）之前所做的任何操作。因此，请删除BUG（）调用并进行正确的错误处理。这与下面链接的syzbot报告有关，但并没有解决它，因为它只防止命中BUG（），它并没有解决我们试图以某种方式对不同索引项使用两倍相同索引号的问题。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52570

description

In the Linux kernel, the following vulnerability has been resolved: vfio/mdev: Fix a null-ptr-deref bug for mdev_unregister_parent() Inject fault while probing mdpy.ko, if kstrdup() of create_dir() fails in kobject_add_internal() in kobject_init_and_add() in mdev_type_add() in parent_create_sysfs_files(), it will return 0 and probe successfully. And when rmmod mdpy.ko, the mdpy_dev_exit() will call mdev_unregister_parent(), the mdev_type_remove() may traverse uninitialized parent->types[i] in parent_remove_sysfs_files(), and it will cause below null-ptr-deref. If mdev_type_add() fails, return the error code and kset_unregister() to fix the issue. general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 2 PID: 10215 Comm: rmmod Tainted: G W N 6.6.0-rc2+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__kobject_del+0x62/0x1c0 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 24 01 00 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8 RSP: 0018:ffff88810695fd30 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffffa0270268 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000004 RDI: 0000000000000010 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10233a4ef1 R10: ffff888119d2778b R11: 0000000063666572 R12: 0000000000000000 R13: fffffbfff404e2d4 R14: dffffc0000000000 R15: ffffffffa0271660 FS: 00007fbc81981540(0000) GS:ffff888119d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc14a142dc0 CR3: 0000000110a62003 CR4: 0000000000770ee0 DR0: ffffffff8fb0bce8 DR1: ffffffff8fb0bce9 DR2: ffffffff8fb0bcea DR3: ffffffff8fb0bceb DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? __kobject_del+0x62/0x1c0 kobject_del+0x32/0x50 parent_remove_sysfs_files+0xd6/0x170 [mdev] mdev_unregister_parent+0xfb/0x190 [mdev] ? mdev_register_parent+0x270/0x270 [mdev] ? find_module_all+0x9d/0xe0 mdpy_dev_exit+0x17/0x63 [mdpy] __do_sys_delete_module.constprop.0+0x2fa/0x4b0 ? module_flags+0x300/0x300 ? __fput+0x4e7/0xa00 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fbc813221b7 Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe780e0648 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 00007ffe780e06a8 RCX: 00007fbc813221b7 RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055e214df9b58 RBP: 000055e214df9af0 R08: 00007ffe780df5c1 R09: 0000000000000000 R10: 00007fbc8139ecc0 R11: 0000000000000206 R12: 00007ffe780e0870 R13: 00007ffe780e0ed0 R14: 000055e214df9260 R15: 000055e214df9af0 Modules linked in: mdpy(-) mdev vfio_iommu_type1 vfio [last unloaded: mdpy] Dumping ftrace buffer: (ftrace buffer empty) —[ end trace 0000000000000000 ]— RIP: 0010:__kobject_del+0x62/0x1c0 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 24 01 00 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8 RSP: 0018:ffff88810695fd30 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffffa0270268 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000004 RDI: 0000000000000010 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10233a4ef1 R10: ffff888119d2778b R11: 0000000063666572 R12: 0000000000000000 R13: fffffbfff404e2d4 R14: dffffc0000000000 R15: ffffffffa0271660 FS: 00007fbc81981540(0000) GS:ffff888119d00000(000 —truncated—

中文

在Linux内核中，已解决以下漏洞：vfio/mdev:修复了mdev_unregister_parent（）的空ptr deref错误。在探测mdpy.ko时注入错误，如果create_dir（）的kstrdup（）在parent_create_sysfs_files（）的mdev_type_add（）中的kobject_init_and_add（中的koobject_add_internal（）中失败，它将返回0并成功探测。当rmmod mdpy.ko时，mdpy_dev_exit（）将调用mdev_unregister_parent（），mdev_type_remove（）可能遍历parent_move_sysfs_files（）中未初始化的parent->types[i]，并将导致以下空ptr deref。如果mdev_type_add（）失败，则返回错误代码和kset_unregister（）以修复问题。一般保护故障，可能是针对非规范地址0xdffffc0000000002:0000[#1]PREEMPT SMP KASAN KASAN:范围为[0x000000000000010-0x0000000000000017]CPU:2 PID:10215通信：rmmod Tained:G W N 6.6.0-rc2+#20硬件名称：QEMU标准PC（i440FX+PIX，1996），BIOS 1.15.0-1 2014年1月4日RIP:0010：__kobject_del+0x62/0x1c0代码：48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 48 b8 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48c1 ea 03<80>3c 02 0 0f 85 24 01 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8 RSP:0018:fffffffff88810695fd30 EFLAGS:000010202 RAX:dffffc0000000000 RBX:ffffffff a0270268 RCX:0000000000000000 RDX:000000000000000 2 RSI:000000000000000 4 RDI:0000000000000010 RBP:00000000000000000 R08:000000000000000 1 R09:ffffed10233a4ef1 R10:ffffff888119d2778b R11:00000000 63666572 R12:000000000000000000000000 R13:fffff bfff404e2d4 R14:dffffc0000000000 R15:ffffff a0271660 FS:00007fbc81981540（0000）GS:ffff888119 d00000（0000）knlGS:0000000000000000 CS:0010 DS:0000 ES:0000 CR0:00000000 80050033 CR2:00007fc14a142dc0 CR3:0000000 110a62003 CR4:0000000000 770ee0 DR0:ffffffff 8fb0bce8 DR1:ffffffffoff 8fb0BCe9 DR2:fffffff 8fb0Bcea DR3:ffffffffeff 8fb0 bceb DR6:00000000 fffe0f0 DR7:0000000000000600 PKRU:55555555 4呼叫跟踪：？die_addr+0x3d/0xa0？exc_general-protection+0x144/0x220？asm_exc_general-protection+0x22/0x30__kobject_del+0x62/0x1c0 kobject_del+0x32/0x50 parent_move_sysfs_files_0xd6/0x170[mdev]mdev_unregister_parent+0xfb/0x190[mdev]？mdev_register_paparent+0x270/0x270[mdev]？find_module_all+0x9d/0xe0 mdpy_dev_exit+0x17/0x63[mdpy]__do_sys_delete_module.constprop.0+0x2fa/0x4b0？module_flags+0x300/0x300__fput+0x4e7/0xa00 do_syscall_64+0x35/0x80 entry_syscall_64_after_hwframe+0x46/0xb0 RIP:003:0x7fbc813221b7代码：73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 84 00 00 00 00 0f 1 f 44 00 00 b8 b0 00 00 00 0 0f 05<48>3d 01 f0 ff 73 01 c348 8b 0d a1 8c 2 c 00 f7 d 8 64 89 08 RSP:002b：00007ffe780e0648 EFLAGS:000000206 ORIG_RAX:000000000000000b0 RAX:fffffffffff daRBX:0007ffe780e06a8 RCX:0007fbc813221b7 RDX:0000000000000000 a RSI:0000000000000800 RDI:000055e214df9b58 RBP:000055e214df9af0 R08:00007ffe780df5c1 R09:000000000000000000000000 R10:00007fbc8139ecc0 R11:0000000000000206 R12:00007ffe780e0870 R13:00007ffe780 e0ed0 R14:000055e214 df9260 R15:000055e214%df9af0链接在：mdpy（-）mdev vfio_iommu>中的模块_type1 vfio[上次卸载：mdpy]转储ftrace缓冲区：（ftrace缓冲器为空）—[结束跟踪0000000000000000]—RIP:0010：__kobject_del+0x62/0x1c0代码：48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 48 b8 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48c1 ea 03<80>3c 02 00f 85 24 01 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8 RSP:0018:fffffffff88810695fd30 EFLAGS:000010202 RAX:dffffc0000000000 RBX:ffffff a0270268 RCX:0000000000000000 RDX:0000000000000000 2 RSI:000000000000000 4 RDI:0000000000000010 RBP:0000000000000000 R08:000000000000000 1 R09:ffffed10233a4ef1 R10:ffffff888119d2778b R11:00000000 63666572 R12:0000000000000000 R13:fffff bfff404e2d4 R14:dffffc0000000000 R15:ffffffffff a0271660 FS:00007fbc81981540（0000）GS:ffffff 888119d00000（000–截断—

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52571

description

In the Linux kernel, the following vulnerability has been resolved: power: supply: rk817: Fix node refcount leak Dan Carpenter reports that the Smatch static checker warning has found that there is another refcount leak in the probe function. While of_node_put() was added in one of the return paths, it should in fact be added for ALL return paths that return an error and at driver removal time.

中文

在Linux内核中，已解决以下漏洞：power:supply:rk817:修复节点refcount泄漏Dan Carpenter报告称，Smatch静态检查器警告发现探测函数中存在另一个refcount泄漏。虽然of_node_put（）被添加到其中一个返回路径中，但事实上，它应该被添加到所有返回错误的返回路径以及在删除驱动程序时。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52572

description

In the Linux kernel, the following vulnerability has been resolved: cifs: Fix UAF in cifs_demultiplex_thread() There is a UAF when xfstests on cifs: BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923 CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 … Call Trace: dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 kasan_check_range+0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Allocated by task 923: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x54/0x60 kmem_cache_alloc+0x147/0x320 mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Freed by task 921: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 kmem_cache_free+0xe3/0x4d0 cifs_small_buf_release+0x29/0x90 SMB2_negotiate+0x8b7/0x1c60 smb2_negotiate+0x51/0x70 cifs_negotiate_protocol+0xf0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The UAF is because: mount(pid: 921) | cifsd(pid: 923) ——————————-|——————————- | cifs_demultiplex_thread SMB2_negotiate | cifs_send_recv | compound_send_recv | smb_send_rqst | wait_for_response | wait_event_state [1] | | standard_receive3 | cifs_handle_standard | handle_mid | mid->resp_buf = buf; [2] | dequeue_mid [3] KILL the process [4] | resp_iov[i].iov_base = buf | free_rsp_buf [5] | | is_network_name_deleted [6] | callback 1. After send request to server, wait the response until mid->mid_state != SUBMITTED; 2. Receive response from server, and set it to mid; 3. Set the mid state to RECEIVED; 4. Kill the process, the mid state already RECEIVED, get 0; 5. Handle and release the negotiate response; 6. UAF. It can be easily reproduce with add some delay in [3] - [6]. Only sync call has the problem since async calls callback is executed in cifsd process. Add an extra state to mark the mid state to READY before wakeup the waitter, then it can get the resp safely.

中文

在Linux内核中，已解决以下漏洞：cifs:修复cifs_demultiplex_thread中的UAF（）当xfstests在cifs:BUG:KASAN:在smb2_is_network_name_deleted+0x27/0x160中释放后使用时存在UAF任务cifsd/923 CPU:1 PID:923 Comm:cifsd未受污染6.1.0-rc4+#45读取addr ffff88810103fc08中的大小4。。。调用跟踪：dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 kasan_check_range+0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cocold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30由任务923分配：kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30__kasan_slab_alloc+0x54/0x60 kmem_cache_alloc+0x147/0x320mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30由任务921释放：kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_seave_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x10b0 kmem_cache_free+0xe3/0x4d0 cifs_ssmall_buf_release+0x29/0x90 SMB2协商+0x8b7/0x1c60smb2_negotiate+0x51/0x70 cifs_egotiate_protocol+0xf0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smbb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_syscall_64_after_hwframe+0x46/0xb0 UAF是因为：mount（pid:921）|cifsd（pid:923）——————————-|——————————-| cifs_sdemultiplex_thread SMB2_express |cifs_send_recv|compound_send_recv|smb_send_rqst|wait_for_response|wait_event_state[1]||standard_receive3|cifs_handle_standard|handle_mid|mid->resp_buf=buf；[2] |dequeue_mid[3]杀死进程[4]|resp_iov[i].iov_base=buf|free_rsp_buf[5]|is_network_name_deleted[6]|回调1。将请求发送到服务器后，等待响应，直到mid->mid_state！=提交；2.接收来自服务器的响应，并将其设置为mid；3.将中间状态设置为RECEIVED；4.杀死进程，中间状态已经RECEIVED，得到0；5.处理并发布协商响应；6.UAF。在[3]-[6]中添加一些延迟可以很容易地再现它。只有同步调用有问题，因为异步调用回调是在cifsd进程中执行的。在唤醒等待者之前，添加一个额外的状态将中间状态标记为READY，这样它就可以安全地获得呼吸。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52573

description

In the Linux kernel, the following vulnerability has been resolved: net: rds: Fix possible NULL-pointer dereference In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists before dereferencing it as rdma_set_service_type() argument Found by Linux Verification Center (linuxtesting.org) with SVACE.

中文

在Linux内核中，已解决以下漏洞：net:rds：修复可能的NULL指针取消引用在rds_rdma_cm_event_handler_cmn（）检查中，如果在将连接指针取消引用为rdma_set_service_type（）参数之前存在连接指针，则由Linux验证中心（linuxtesting.org）使用SVACE找到。

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52574

description

In the Linux kernel, the following vulnerability has been resolved: team: fix null-ptr-deref when team device type is changed Get a null-ptr-deref bug as follows with reproducer [1]. BUG: kernel NULL pointer dereference, address: 0000000000000228 … RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q] … Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x82/0x150 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x26/0x30 ? vlan_dev_hard_header+0x35/0x140 [8021q] ? vlan_dev_hard_header+0x8e/0x140 [8021q] neigh_connected_output+0xb2/0x100 ip6_finish_output2+0x1cb/0x520 ? nf_hook_slow+0x43/0xc0 ? ip6_mtu+0x46/0x80 ip6_finish_output+0x2a/0xb0 mld_sendpack+0x18f/0x250 mld_ifc_work+0x39/0x160 process_one_work+0x1e6/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 [1] $ teamd -t team0 -d -c {“runner”: {“name”: “loadbalance”}} $ ip link add name t-dummy type dummy $ ip link add link t-dummy name t-dummy.100 type vlan id 100 $ ip link add name t-nlmon type nlmon $ ip link set t-nlmon master team0 $ ip link set t-nlmon nomaster $ ip link set t-dummy up $ ip link set team0 up $ ip link set t-dummy.100 down $ ip link set t-dummy.100 master team0 When enslave a vlan device to team device and team device type is changed from non-ether to ether, header_ops of team device is changed to vlan_header_ops. That is incorrect and will trigger null-ptr-deref for vlan->real_dev in vlan_dev_hard_header() because team device is not a vlan device. Cache eth_header_ops in team_setup(), then assign cached header_ops to header_ops of team net device when its type is changed from non-ether to ether to fix the bug.

中文

在Linux内核中，以下漏洞已得到解决：team:修复更改团队设备类型时的null ptr deref。使用repeater[1]获取null ptr defef错误，如下所示。BUG：内核NULL指针取消引用，地址：0000000000000228。。。RIP：0010:vlan_dev_hard_header+0x35/0x140[8021q]。。。呼叫跟踪：＜TASK＞__骰子+0x24/0x70？page_fault_ops+0x82/0x150？exc_page_fault+0x69/0x150？asm_exc_page_fault+0x26/0x30？vlan_dev_hard_header+0x35/0x140[8021q]？vlan_dev_hard_header+0x8e/0x140[8021q]neigh_connected_output+0x2/0x100 ip6_finish_output2+0x1cb/0x520？nf_hook_slow+0x43/0xc0？ip6_mtu+0x46/0x80 ip6_finish_output+0x2a/0xb0 mld_sendpack+0x18f/0x250 mld_ifc_work+0x39/0x160 process_one_work+0x1e6/0x3f0 worker_thread+0x4d/0x2f0__pfx_worker_thread+0x10/0x10-kthread+0xe5/0x120__pfx_k线程+0x10/0x10 ret_from_fork+0x34/0x50__pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30[1]$teamd-t team0-d-c｛“runner”：｛“name”：“loadbalance”｝｝$ip链接添加名称t-dummy类型dummy$ip链接添加链接t-dummy-name t-dummy.100类型vlan id 100$ip链接增加名称t-nlmon类型nlmon$ip链接设置t-nlmon主team0$ip链接集t-nlmon正常主机$ip链接设置t-dummyup$ip链接集合team0 up$ip链路集t-dummy100 down$ip链路设置t-dummy200主team0从属于vlan时n设备更改为团队设备，团队设备类型从非以太更改为以太，团队设备的header_ops更改为vlan_header_ops。这是不正确的，并且将在vlan_dev_hard_header（）中触发vlan->real_dev的空ptr deref，因为团队设备不是vlan设备。在team_setup（）中缓存eth_header_ops，然后当其类型从非以太更改为以太时，将缓存的header_ops分配给团队网络设备的header_op以修复错误。

cvss epss percentile
None 0.04% 10.69%

references

CVE-2023-52575

description

In the Linux kernel, the following vulnerability has been resolved: x86/srso: Fix SBPB enablement for spec_rstack_overflow=off If the user has requested no SRSO mitigation, other mitigations can use the lighter-weight SBPB instead of IBPB.

中文

在Linux内核中，已解决以下漏洞：x86/srso:修复spec_rstack_overflow=off的SBPB启用如果用户没有请求srso缓解措施，其他缓解措施可以使用重量较轻的SBPB而不是IBPB。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52576

description

In the Linux kernel, the following vulnerability has been resolved: x86/mm, kexec, ima: Use memblock_free_late() from ima_free_kexec_buffer() The code calling ima_free_kexec_buffer() runs long after the memblock allocator has already been torn down, potentially resulting in a use after free in memblock_isolate_range(). With KASAN or KFENCE, this use after free will result in a BUG from the idle task, and a subsequent kernel panic. Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid that bug.

中文

在Linux内核中，已解决以下漏洞：x86/mm，kexec，ima:从ima_free_kexec_buffer（）使用memblock_free_late（。对于KASAN或KFENCE，这种释放后的使用将导致空闲任务的BUG，以及随后的内核死机。将ima_free_kexec_buffer（）切换到memblock_free_late（）以避免该错误。

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52577

description

In the Linux kernel, the following vulnerability has been resolved: dccp: fix dccp_v4_err()/dccp_v6_err() again dh->dccph_x is the 9th byte (offset 8) in “struct dccp_hdr”, not in the “byte 7” as Jann claimed. We need to make sure the ICMP messages are big enough, using more standard ways (no more assumptions). syzbot reported: BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2667 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2681 [inline] BUG: KMSAN: uninit-value in dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94 pskb_may_pull_reason include/linux/skbuff.h:2667 [inline] pskb_may_pull include/linux/skbuff.h:2681 [inline] dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94 icmpv6_notify+0x4c7/0x880 net/ipv6/icmp.c:867 icmpv6_rcv+0x19d5/0x30d0 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:304 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:304 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5523 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x83b/0x920 tun_get_user+0x564c/0x6940 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:1985 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x15c0 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6313 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x23cf/0x6940 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:1985 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x15c0 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 0 PID: 4995 Comm: syz-executor153 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023

中文

在Linux内核中，以下漏洞已被解决：dccp:fix dccp_v4_err（）/dccp_v6_err（）again dh->dccph_x是“struct dccp_hdr”中的第9个字节（偏移量8），而不是Jann所说的“byte 7”。我们需要确保ICMP消息足够大，使用更标准的方式（没有更多的假设）。syzbot报告：BUG:KMSAN:pskb_may_pull_reason中的uninit值include/linux/skbuff。h:2667[inline]BUG:KMSAN:pskb_may_pull include/linux-skbuff中的uninit值。h:2681[inline]BUG:CMSAN:dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6中的unimit值。c:94 pskb_may_pull_reason-include/linux/skbuff。h：2667[inline]pskb_max_pull include/unux/skbuffdccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94 icmpv6_notify+0x4c7/0x880 net/ipv6/icmp.c:867 icmpv6_rcv+0x19d5/0x30d0 ip6_procol_delivery_rcu+0xda6/0x2a60 net/ipv6_input.c:438 ip6_input_finish net/ipv6-ip6_input。c:483[inline]NF_HOOK include/linux/netfilter.h:304[iinline]ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6_input.c:586 dst_input include/net/dst.h:468[inline]ip6_rcv_finish+0x5db/0x870 net/ipv6/6_input.c:79 NF_HOOK include/linux/netfilter.h:304[inline]ipv6_rcv+0xda/0x390 net/ipv6-ip6_ininput.c:310 __netif_rereceive_skb_one_core net/core/dev.c:5523[内联]__netif_rereceive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723[inline]netif-rereceive_skb+0x58/0x660 net/core-dev.c:5782 tun_rx_batched+0x83b/0x920 tun_get_user+0x564c/0x6940 drivers/net/tun.c:2002 tun_chr_write_inter+0x3af/0x5d0 drivers/net-tun.c:22048 call_write_inter include/linux/fs.h:1985[inline]new_sync_write-fs/read_write.c:491[内联]vfs_write+0x8ef/0x15c0 fs/read_write。c:584 ksys_write+0x20f/0x4c0 fs/read _write，c:637 __do_sys_write fs/read-write。c:649[inline]__se_sys_wwrite fs/read-write，c:646[inline]__x64_sys_write+0x93/0xd0 fs/red _write；c:646 do_syscall_x64 arch/x86/entry/common。c:50[inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_syscall_64_after_hwframe+0x63/0xcd Uninit创建于：slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub。c:3478[inline]kmem_cache_alloc_node+0x577/0xa80 mm/slub buff.c:650 alloc_skb include/linux/skbuff.h:1286[inline]alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuf.c:6313 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1531[inline]tun_get_user+0x23cf/0x6940 drivers/nt/tun.c:1846 tun_chr_write_inter+0x3af/0x5d0 drivers/net/tun.c:22048 call_write_inter include/linux/fs.h:1985[inline]new_sync_write-fs/read_write.c:491[inline]vfs_write+0x8ef/0x15c0 fs/read_write。c:584 ksys_write+0x20f/0x4c0 fs/read _write，c:637 __do_sys_write fs/read-write。c:649[inline]__se_sys_wwrite fs/read-write，c:646[inline]__x64_sys_write+0x93/0xd0 fs/red _write；c:646 do_syscall_x64 arch/x86/entry/common。c:50[inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_syscall_64_after_hwframe+0x63/0xcd CPU:0 PID:4995通信：syz-execution153未受污染6.6.0-rc1-syzcaller-00014-ga747acc0b752#0硬件名称：谷歌谷歌计算引擎/谷歌计算引擎，BIOS谷歌08/04/2023

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52578

description

In the Linux kernel, the following vulnerability has been resolved: net: bridge: use DEV_STATS_INC() syzbot/KCSAN reported data-races in br_handle_frame_finish() [1] This function can run from multiple cpus without mutual exclusion. Adopt SMP safe DEV_STATS_INC() to update dev->stats fields. Handles updates to dev->stats.tx_dropped while we are at it. [1] BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 NF_HOOK include/linux/netfilter.h:304 [inline] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline] nf_hook_bridge_pre net/bridge/br_input.c:272 [inline] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417 __netif_receive_skb_one_core net/core/dev.c:5521 [inline] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_poll net/core/dev.c:6594 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 run_ksoftirqd+0x17/0x20 kernel/softirq.c:921 smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 NF_HOOK include/linux/netfilter.h:304 [inline] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline] nf_hook_bridge_pre net/bridge/br_input.c:272 [inline] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417 __netif_receive_skb_one_core net/core/dev.c:5521 [inline] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_poll net/core/dev.c:6594 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356 batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560 process_one_work kernel/workqueue.c:2630 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703 worker_thread+0x525/0x730 kernel/workqueue.c:2784 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 value changed: 0x00000000000d7190 -> 0x00000000000d7191 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0

中文

在Linux内核中，已解决以下漏洞：net:bridge:use DEV_STATS_INC（）syzbot/KCSAN reported data races In br_handle_frame_finish（）[1]此函数可以从多个cpu运行，而不会相互排斥。采用SMP安全的DEV_STATS_INC（）更新DEV->STATS字段。处理dev->stats.tx_dropped的更新。[1]BUG:KCSAN：通过cpu 1上的中断，br_handle_frame_finish/br_handle_frame_finish读写到0xffff8881374b2178（共8个字节）的数据竞赛：br_handl_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hhook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 nf_hook include/linux/netfilter.h:304[inline]br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf.pre_routing+0x526/0xba0 net/bridge/br_netfilter _hooks。c:508 nf_hook_entry_hookfn include/linux/netfilter。h:144[inline]nf_hook_bridge_pre net/bridges/br_input。c:272[iinline]br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_rereceive_skb_core+0xa8a/0x21e0 net/core/dev.c:55417 __netif-rereceive_skb_one_core net/core/dev.c:5521[inline]__netif/rereceive_skb+0x57/0x1b0 net/core-dev.c:5637 process_backlog+0x21f/0x380 net/core/div.c:55965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_polll net/core/dev.c:6594[内联]net_rx_action+0x32b/0x750 net/core/dev.c:6727__do_softirq+0xc1/0x265 kernel/softirq.c:553 run_ksoftirqd+0x17/0x20 kernel/ssoftirq.c:921 smpboot_thread_fn+0x30a/0x4a0kernel/spboot.c:164 kthread+0x1d7/0x210 kernel/khread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from-fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304通过中断读写到8字节的0xffff8881374b2178在cpu 0上：br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input。c:189 br_nf_chook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 nf_hook include/linux/netfilter。h:304[inline]br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6。c:178 br_nf_fre_routing+0x526/0xba0 net/bBridge/br_netfilter _hooks。c:508 nf_hook_entry_hookfn include/linux/netfilter.h:144[inline]nf_hook_bridge_pre net/bridge/br_input.c:272[inline]br_handle_frame+0x4c9/0x940 net/bridge/br_input:c:417 __netif_rereceive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417__netif-rereceive_skb_one_core net/core/dev.c:5521[inline]__netif_areceive_skb+0x57/0x1b0 net/core/dev.c:5637 process_backlog+0x21f/0x380 net/core/dev.c:55965 __napi_poll+0x60/0x3b0 net-core/dev.c:6527 napi_polll net/core-dev.c:6594[内联]net_rx_action+0x32b/0x750 net/core/dev.c:66727 __do_softirq+0xc1/0x265内核/softirq.c:553 do_softirq+0x5e/0x90内核/softirq.c:454 __local_bh_enable_ip+0x64/0x70内核/softir q.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167[inline]_raw_spin_uunlock_bh+0x36/0x40内核/spinlock.c:210 spin_unlock_bh include/liinux/spinlock.h:396[内联]batadv_tt_local_purge+0x1a8/0x1f0 net/batman adv/翻译表。c:1356 batadv_tt_purge+0x2b/0x630 net/batman-adv/翻译表，c:3560 process_one_work内核/工作队列。c:2630[inline]process_scheduled_works+0x5b8/0xa30 kernel/workqueue。c:2703 worker_thread+0x525/0x730 kernel/wworkqueue。c:\2784 kthread+0x1d7/0x210 kernel/khread。c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process。c:147 ret_from-fork_asm+0x11/0x20 arch/x86/entry/entry_64。S:304值已更改：0x00000000000d7190->0x00000000000d7.11由内核并发性Sanitizer报告：CPU:0 PID:14848通信：kworker/u4:11未受污染6.6.0-rc1-syzcaller-00236-gad8a69f361b9#0

cvss epss percentile
None 0.04% 8.20%

references

CVE-2023-52579

description

In the Linux kernel, the following vulnerability has been resolved: ipv4: fix null-deref in ipv4_link_failure Currently, we assume the skb is associated with a device before calling __ip_options_compile, which is not always the case if it is re-routed by ipvs. When skb->dev is NULL, dev_net(skb->dev) will become null-dereference. This patch adds a check for the edge case and switch to use the net_device from the rtable when skb->dev is NULL.

中文

在Linux内核中，以下漏洞已被解决：ipv4:修复ipv4_link_failure中的null deref当前，我们假设skb在调用__ip_options_comple之前与设备关联，如果它被ipv重新路由，则情况并非总是如此。当skb->dev为NULL时，dev_net（skb->dev）将变为NULL解引用。此补丁添加了对边缘情况的检查，并在skb->dev为NULL时切换到使用rtable中的net_device。

cvss epss percentile
None 0.04% 10.69%

references

CVE-2023-52580

description

In the Linux kernel, the following vulnerability has been resolved: net/core: Fix ETH_P_1588 flow dissector When a PTP ethernet raw frame with a size of more than 256 bytes followed by a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculation is wrong. For example: hdr->message_length takes the wrong value (0xffff) and it does not replicate real header length. In this case, nhoff value was overridden and the PTP header was badly dissected. This leads to a kernel crash. net/core: flow_dissector net/core flow dissector nhoff = 0x0000000e net/core flow dissector hdr->message_length = 0x0000ffff net/core flow dissector nhoff = 0x0001000d (u16 overflow) … skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Using the size of the ptp_header struct will allow the corrected calculation of the nhoff value. net/core flow dissector nhoff = 0x0000000e net/core flow dissector nhoff = 0x00000030 (sizeof ptp_header) … skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff skb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Kernel trace: [ 74.984279] ————[ cut here ]———— [ 74.989471] kernel BUG at include/linux/skbuff.h:2440! [ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1 [ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023 [ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130 [ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9 [ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297 [ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003 [ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300 [ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800 [ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010 [ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800 [ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000 [ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0 [ 75.121980] PKRU: 55555554 [ 75.125035] Call Trace: [ 75.127792] [ 75.130063] ? eth_get_headlen+0xa4/0xc0 [ 75.134472] igc_process_skb_fields+0xcd/0x150 [ 75.139461] igc_poll+0xc80/0x17b0 [ 75.143272] __napi_poll+0x27/0x170 [ 75.147192] net_rx_action+0x234/0x280 [ 75.151409] __do_softirq+0xef/0x2f4 [ 75.155424] irq_exit_rcu+0xc7/0x110 [ 75.159432] common_interrupt+0xb8/0xd0 [ 75.163748] [ 75.166112] [ 75.168473] asm_common_interrupt+0x22/0x40 [ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350 [ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1 [ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202 [ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f [ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20 [ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001 [ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980 [ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000 [ 75.245635] ? —truncated—

中文

在Linux内核中，已解决以下漏洞：net/core:修复ETH_P588流解析器当向__skb_flow_dssect发送大小超过256字节、后跟0xff模式的PTP以太网原始帧时，nhoff值计算错误。例如：hdr->message_length采用了错误的值（0xffff），并且它不会复制实际的标头长度。在这种情况下，nhoff值被覆盖，PTP标头被严重分解。这会导致内核崩溃。net/core：流量解析器net/core流量解析器nhoff=0x0000000e net/core流解析器hdr->message_length=0x0000ffff net-core流解析器nhoff＝0x0001000d（u16溢出）。。。skb线性：00000000:00 a0 c9 00 00 00 a0 c90 00 00 00 88 skb碎片：00000000:f7 ff ff ff ff ffff ff ff使用ptp_header结构的大小将允许对nhoff值进行校正计算。网/核心流量剖析器nhoff=0x0000000e网/核心流剖析器nhof=0x00000030（ptp_header的大小）。。。skb线性：00000000:00 a0 c9 00 00 00 00 a0 c0 00 00 00 88 f7 ff ff skb线性:00000010:ff ff ff ff ffff ff ffffff ffff ffb线性：00000020:ff ff ff off ff ffff off ff ff fff ff ff ff f ff ff ffb片段：00000000:ff ff ff iff ff ff ff offff ff ff ff ffff ff ff内核跟踪：[74.984279]—————[此处剪切]-[74.9989471]内核BUG在include/linux/skbuff.h:2440！[74.995237]无效操作码：0000[#1]PREEMPT SMP NOPTI[75.0010198]CPU:4 PID:0 Comm:swaper/4 Tained:G U 5.15.85-intel-ese-standard-lts#1[75.011629]硬件名称：intel Corporation A-Island（CPU:AlderLake）/A-Island（ID:06），BIOS SB_ADLP.0.01.00.01.03.008.D-6A9D9E73-第三方2023年3月30日[75.026507]RIP:0010：eth_type_trans+0xd0/0x130[75.0031594]代码：03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 eb ab＜0f＞0b b8 00 01 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9【75.052612】RSP:0018:ffffffff9948c0228de0 EFLAGS:000010297【75.058473】RAX:000000000000003f2 RBX:fffffff8e47047dc300 RCX:00000000000001003【75.06462】RDX:ffff8e4e8c9ea040 RSI:ffffff8e4704e00RDI:ffff8e47047dc300[75.074558]RBP:fff8e4704 e2acc0 R08:00000000000003f3 R09:0000000000000800[75.082466]R10:0000000000000000 d R11:ffff9948c0228dec R12:ffffff8 e4715e4e010[75.090461]R13:ff9948c0545018 R14:000000000000000 1 R15:0000000000000800[75.0098464]FS:000000000000000（0000）GS:ff8e4e8e8 fb00000（0000）knlGS:0000000000000000[75.107530]CS:0010 DS:0000 ES:0000 CR:000000000 80050033[75.113982]CR2:00007f5eb35934a00 CR3:0000000 150e0a002 CR4:0000000000 770ee0[75.121980]PKRU:555555555 4[75.125035]呼叫跟踪：[75.1127792]＜IRQ>[75.130063]？eth_get_headlen+0xa4/0xc0【75.134472】igc_process_skb_fields+0xcd/0x150【75.139461】igc_poll+0xc80/0x17b0【75.143272】__napi_poll+0x27/0x170【75.147192】net_rx_action+0x234/0x280【75.151409】__do_softirq+0xef/0x2f4【75.155424】irq_exit_rcu+0xc7/0x110【75.159432】common_interrupt+0xb8/0xd0【75.163748】【75.166 112]<任务>[75.168473]asm_common_interrupt+0x22/0x40[75.173175]RIP:0010：cpuidle_enter_state+0xe2/0x350[75.178749]代码：85 c0 0f 8f 04 02 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 31 ffe 8 52 b0 6d ff fb 45 85 f6<0f>88 b1 00 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1[75.1997 57]RSP:0018:ffffff9948c013bea8 EFLAGS:000000202[75.205614]RAX:fffff8e4e8fb00000 RBX:fffb948bfd23900 RCX:0000000000000001f[75.213619]RDX:000000000000004 RSI:ffffffffff 94206161 RDI:ffffff 94.212e20[75.221620]RBP:0000000000000000 4 R08:000000117568973a R09:0000000000000001[75.222622]R10:0000000000000 afc8 R11:ffffff8e8fb29ce4 R12:ffffffiffff 945ae980[75.237628]R13:000000117568983a R14:000000000000004 R14 5:000000000000000000000000[75.245635] ? —截断的—

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-52581

description

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix memleak when more than 255 elements expired When more than 255 elements expired were supposed to switch to a new gc container structure. This never happens: u8 type will wrap before reaching the boundary and nft_trans_gc_space() always returns true. This means we recycle the initial gc container structure and lose track of the elements that came before. While at it, dont deref gc after weve passed it to call_rcu.

中文

在Linux内核中，已解决以下漏洞：netfilter:nf_tables:fix memleak when than 255 elements expired when than 255elements过期本应切换到新的gc容器结构。这种情况永远不会发生：u8类型将在到达边界之前进行包装，nft_trans_gc_space（）始终返回true。这意味着我们回收最初的gc容器结构，并丢失之前的元素。同时，不要在我们将gc传递给call_rcu之后取消它。

cvss epss percentile
None 0.04% 6.96%

references

CVE-2023-52582

description

In the Linux kernel, the following vulnerability has been resolved: netfs: Only call folio_start_fscache() one time for each folio If a network filesystem using netfs implements a clamp_length() function, it can set subrequest lengths smaller than a page size. When we loop through the folios in netfs_rreq_unlock_folios() to set any folios to be written back, we need to make sure we only call folio_start_fscache() once for each folio. Otherwise, this simple testcase: mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s echo 3 > /proc/sys/vm/drop_caches cat /mnt/nfs/file.bin > /dev/null will trigger an oops similar to the following: page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio)) ————[ cut here ]———— kernel BUG at include/linux/netfs.h:44! … CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5 … RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs] … Call Trace: netfs_rreq_assess+0x497/0x660 [netfs] netfs_subreq_terminated+0x32b/0x610 [netfs] nfs_netfs_read_completion+0x14e/0x1a0 [nfs] nfs_read_completion+0x2f9/0x330 [nfs] rpc_free_task+0x72/0xa0 [sunrpc] rpc_async_release+0x46/0x70 [sunrpc] process_one_work+0x3bd/0x710 worker_thread+0x89/0x610 kthread+0x181/0x1c0 ret_from_fork+0x29/0x50

中文

在Linux内核中，以下漏洞已被解决：netfs：每个folio只调用folio_start_fscache（）一次。如果使用netfs的网络文件系统实现了clamp_length（）函数，它可以将子请求长度设置为小于页面大小。当我们循环浏览netfs_rreq_unlock_folios（）中的对开本以设置要写回的任何对开本时，我们需要确保对每个对开本只调用folio_start_fscache（）一次。否则，这个简单的测试用例：mount-o fsc，rsize=1024，wsize=1024 127.0.0.1:/export/mnt/nfs-dd if=/dev/zero-of=/mnt/nfs/file.bin bs=4096 count=1 1+0记录中的1+0记录复制4096字节（4.1 kB，4.0 KiB），0.0126359 s，324 kB/s echo 3>/proc/sys/vm/drop_caches cat/mnt/nfs/file.bin>/dev/null将触发类似于以下内容的oops：页面转储是因为：vm_BUG_ON_FOLIO（FOLIO_test_private_2（FOLIO））—————[此处剪切]—————-内核BUG at include/linux/netfs.h:44。。。CPU:5 PID:134通信：kworker/u16:5 Kdump:已加载未受污染的6.4.0-rc5。。。RIP:0010：netfs_rreq_unlock_folios+0x68e/0x730[netfs]。。。调用跟踪：netfs_rreq_assess+0x497/0x660[netfs]netfs_subreq_terminated+0x32b/0x610[netfs]nfs_netfs_read_completion+0x14e/0x1a0[nfs]nfs_read_complation+0x2f9/0x330[nfs]rpc_free_task+0x72/0xa0[sunrpc]rpc_async_release+0x46/0x70[sunrpc]process_one_work+0x3bd/0x710 worker_thread+0x89/0x610 kthread+0x181/0x1c0 ret_from_fork+0x29/0x50

cvss epss percentile
None 0.04% 12.44%

references

CVE-2023-6326

description

The Master Slider – Responsive Touch Slider plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 3.9.3. This is due to missing or incorrect nonce validation on the process_bulk_action function. This makes it possible for unauthenticated attackers to duplicate or delete arbitrary sliders via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

中文

主滑块&#8211；WordPress的响应式触摸滑块插件在3.9.3之前（包括3.9.3）的所有版本中都容易受到跨站点请求伪造的攻击。这是由于process_bulk_action函数的nonce验证缺失或不正确。这使得未经身份验证的攻击者有可能通过伪造的请求复制或删除任意滑块。他们可以诱使网站管理员执行诸如单击链接之类的操作。

cvss epss percentile
5.4 MEDIUM 0.04% 6.96%

references

CVE-2024-0378

description

The AI Engine: Chatbots, Generators, Assistants, GPT 4 and more! plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the AI chat data when discussion tracking is enabled in all versions up to, and including, 2.2.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

中文

AI引擎：聊天机器人、生成器、助手、GPT 4等等！当在2.2.0之前（包括2.2.0）的所有版本中启用讨论跟踪时，由于输入净化和输出转义不足，WordPress插件容易受到通过AI聊天数据存储的跨站点脚本的攻击。这使得未经身份验证的攻击者有可能在页面中注入任意web脚本，每当用户访问注入的页面时，这些脚本就会执行。

cvss epss percentile
6.5 MEDIUM 0.04% 6.96%

references

CVE-2024-0611

description

The Master Slider – Responsive Touch Slider plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the slides callback functionality in all versions up to, and including, 3.9.5. This makes it possible for authenticated attackers, with editor-level access, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.

中文

主滑块&#8211；WordPress的响应式触摸滑块插件在3.9.5之前（包括3.9.5）的所有版本中都容易通过幻灯片回调功能受到存储的跨站点脚本攻击。这使得具有编辑器级访问权限的经过身份验证的攻击者有可能在页面中注入任意web脚本，每当用户访问注入的页面时，这些脚本就会执行。这只会影响多站点安装和禁用了unstered.html的安装。

cvss epss percentile
4.4 MEDIUM 0.04% 6.96%

references

CVE-2024-0795

description

If an attacked was given access to an instance with the admin or manager role there is no backend authentication that would prevent the attacked from creating a new user with an admin role and then be able to use this new account to have elevated privileges on the instance

中文

如果被攻击者被授予访问具有管理员或管理员角色的实例的权限，则没有后端身份验证可以阻止被攻击者创建具有“管理员”角色的新用户，然后能够使用此新帐户对该实例拥有提升的权限

cvss epss percentile
7.2 HIGH 0.04% 6.96%

references

CVE-2024-0968

description

Cross-site Scripting (XSS) - DOM in GitHub repository langchain-ai/chat-langchain prior to 0.0.0.

中文

跨站点脚本（XSS）-在0.0.0之前的GitHub存储库langchain-ai/chat langchain中的DOM。

cvss epss percentile
4.6 MEDIUM 0.04% 6.96%

references

CVE-2024-1398

description

The Ultimate Bootstrap Elements for Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘heading_title_tag’ and ’heading_sub_title_tag’ parameters in all versions up to, and including, 1.3.6 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

中文

WordPress的Elementor插件的Ultimate Bootstrap Elements易受存储跨站点脚本攻击，通过&#8216；heading_title_tag&#8217；和&#8217；heading_sub_title_tag&#8217；1.3.6之前（包括1.3.6）的所有版本中的参数，因为输入净化和输出转义不足。这使得具有贡献者级别及以上权限的经过身份验证的攻击者有可能在页面中注入任意web脚本，这些脚本将在用户访问注入的页面时执行。

cvss epss percentile
6.4 MEDIUM 0.04% 12.44%

references

CVE-2024-1449

description

The Master Slider – Responsive Touch Slider plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugins ms_slide shortcode in all versions up to, and including, 3.9.5 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

中文

主滑块&#8211；WordPress的响应式触摸滑块插件在3.9.5之前（包括3.9.5）的所有版本中都容易通过插件ms_slide shortcode受到存储的跨站点脚本的攻击，因为用户提供的属性上的输入净化和输出转义不足。这使得具有贡献者级别及以上权限的经过身份验证的攻击者有可能在页面中注入任意web脚本，这些脚本将在用户访问注入的页面时执行。

cvss epss percentile
6.4 MEDIUM 0.04% 6.96%

references

CVE-2024-1592

description

The Complianz – GDPR/CCPA Cookie Consent plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 6.5.6. This is due to missing or incorrect nonce validation on the process_delete function in class-DNSMPD.php. This makes it possible for unauthenticated attackers to delete GDPR data requests via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

中文

合规性&#8211；用于WordPress的GDPR/CPA Cookie同意插件在6.5.6之前（包括6.5.6）的所有版本中都容易受到跨站点请求伪造的攻击。这是由于类-DNSMPD.php中process_delete函数的nonce验证缺失或不正确。这使得未经身份验证的攻击者有可能通过伪造的请求删除GDPR数据请求。他们可以诱骗网站管理员执行诸如点击链接之类的操作。

cvss epss percentile
4.3 MEDIUM 0.04% 6.96%

references

CVE-2024-1775

description

The Nextend Social Login and Register plugin for WordPress is vulnerable to a self-based Reflected Cross-Site Scripting via the ‘error_description’ parameter in all versions up to, and including, 3.1.12 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers, with access to a subscriber-level account, to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link. NOTE: This vulnerability can be successfully exploited on a vulnerable WordPress instance against an OAuth pre-authenticated higher-level user (e.g., administrator) by leveraging a cross-site request forgery in conjunction with a certain social engineering technique to achieve a critical impact scenario (cross-site scripting to administrator-level account creation). However, successful exploitation requires “Debug mode” to be enabled in the plugins “Global Settings”.

中文

WordPress的Nextend社交登录和注册插件容易受到通过&#8216；errordescription&#8217；3.1.12之前（包括3.1.12）的所有版本中的参数，因为输入净化和输出转义不足。这使得未经身份验证的攻击者有可能访问订阅者级别的帐户，在页面中注入任意web脚本，如果他们能够成功地诱骗用户执行诸如单击链接之类的操作，则执行这些脚本。注意：通过利用跨站点请求伪造和特定的社会工程技术，可以在易受攻击的WordPress实例上成功利用此漏洞攻击OAuth预认证的高级用户（例如管理员），以实现关键影响场景（跨站点脚本到管理员级帐户创建）。但是，成功利用此漏洞需要在插件“全局设置”中启用“调试模式”。

cvss epss percentile
5.4 MEDIUM 0.04% 6.96%

references

CVE-2024-2133

description

A vulnerability, which was classified as problematic, was found in Bdtask Isshue Multi Store eCommerce Shopping Cart Solution 4.0. This affects an unknown part of the file /dashboard/Cinvoice/manage_invoice of the component Manage Sale Page. The manipulation of the argument Title leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-255495.

中文

在Bdtask Isshue多商店电子商务购物车解决方案4.0中发现了一个被归类为有问题的漏洞。这会影响组件“管理销售页面”的文件/ddashboard/Cinvoice/manage_invoice的未知部分。对参数Title的操作会导致跨站点脚本编写。可以远程发起攻击。该漏洞已向公众公开，并可能被利用。此漏洞的相关标识符为VDB-255495。

cvss epss percentile
2.4 LOW 0.04% 12.44%

references

CVE-2024-25063

description

Due to insufficient server-side validation, a successful exploit of this vulnerability could allow an attacker to gain access to certain URLs that the attacker should not have access to.

中文

由于服务器端验证不足，成功利用此漏洞可能会使攻击者能够访问攻击者不应该访问的某些URL。

cvss epss percentile
7.5 HIGH 0.04% 6.96%

references

CVE-2024-25064

description

Due to insufficient server-side validation, an attacker with login privileges could access certain resources that the attacker should not have access to by changing parameter values.

中文

由于服务器端验证不足，具有登录权限的攻击者可以通过更改参数值来访问攻击者不应该访问的某些资源。

cvss epss percentile
4.3 MEDIUM 0.04% 6.96%

references

CVE-2024-25865

description

Cross Site Scripting (XSS) vulnerability in hexo-theme-anzhiyu v1.6.12, allows remote attackers to execute arbitrary code via the algolia search function.

中文

hexo主题anzhiyu v1.6.12中的跨站点脚本（XSS）漏洞允许远程攻击者通过算法搜索功能执行任意代码。

cvss epss percentile
None 0.04% 6.96%

references

CVE-2024-26621

description

In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: dont force huge page alignment on 32 bit commit efa7df3e3bb5 (“mm: align larger anonymous mappings on THP boundaries”) caused two issues [1] [2] reported on 32 bit system or compat userspace. It doesnt make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space. [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/

中文

在Linux内核中，已解决以下漏洞：mm:huge_memory:不要在32位提交efa7df3e3bb5上强制进行巨大的页面对齐（“mm:在THP边界上对齐更大的匿名映射”），这导致了32位系统或兼容用户空间上报告的两个问题[1][2]。由于虚拟地址空间的限制，在32位系统上强制进行巨大的页面对齐没有太大意义。1.https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/[2]https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/

cvss epss percentile
None 0.04% 6.96%

references

Modified_entries

CVE-2023-42282

description

The ip package before 1.1.9 for Node.js might allow SSRF because some IP addresses (such as 0x7f.1) are improperly categorized as globally routable via isPublic.

中文

Node.js 1.1.9之前的ip包可能允许SSRF，因为一些ip地址（如0x7f.1）被错误地归类为可通过isPublic全局路由。

cvss epss percentile
None 0.06% 25.26%

references

CVE-2024-2072

description

A vulnerability, which was classified as problematic, was found in SourceCodester Flashcard Quiz App 1.0. This affects an unknown part of the file /endpoint/update-flashcard.php. The manipulation of the argument question/answer leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-255387.

中文

在SourceCodester Flashcard Quiz App 1.0中发现了一个被归类为有问题的漏洞。这会影响文件/endpoint/update-flashcard.php的未知部分。对论点问题/答案的操纵会导致跨站点脚本编写。可以远程发起攻击。该漏洞已向公众公开，并可能被利用。此漏洞的相关标识符为VDB-255387。

cvss epss percentile
3.5 LOW 0.04% 12.44%

references

CVE-2024-23743

description

** DISPUTED ** Notion through 3.1.0 on macOS might allow code execution because of RunAsNode and enableNodeClilnspectArguments. NOTE: the vendor states “the attacker must launch the Notion Desktop application with nonstandard flags that turn the Electron-based application into a Node.js execution environment.”

中文

有争议由于RunAsNode和enableNodeClilnspectArguments，macOS上3.1.0版本的Notion可能允许执行代码。注：供应商表示“攻击者必须使用非标准标志启动Notion Desktop应用程序，这些标志将基于Electron的应用程序转换为Node.js执行环境。”

cvss epss percentile
None 0.08% 31.39%

references