Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-&gt;cork.<br /> <br /> syzbot reported the splat below. [0]<br /> <br /> The repro does the following:<br /> <br /> 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)<br /> 2. Attach the prog to a SOCKMAP<br /> 3. Add a socket to the SOCKMAP<br /> 4. Activate fault injection<br /> 5. Send data less than cork_bytes<br /> <br /> At 5., the data is carried over to the next sendmsg() as it is<br /> smaller than the cork_bytes specified by bpf_msg_cork_bytes().<br /> <br /> Then, tcp_bpf_send_verdict() tries to allocate psock-&gt;cork to hold<br /> the data, but this fails silently due to fault injection + __GFP_NOWARN.<br /> <br /> If the allocation fails, we need to revert the sk-&gt;sk_forward_alloc<br /> change done by sk_msg_alloc().<br /> <br /> Let&amp;#39;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate<br /> psock-&gt;cork.<br /> <br /> The "*copied" also needs to be updated such that a proper error can<br /> be returned to the caller, sendmsg. It fails to allocate psock-&gt;cork.<br /> Nothing has been corked so far, so this patch simply sets "*copied"<br /> to 0.<br /> <br /> [0]:<br /> WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156<br /> Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc<br /> RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246<br /> RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80<br /> RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000<br /> RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4<br /> R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380<br /> R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872<br /> FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> __sk_destruct+0x86/0x660 net/core/sock.c:2339<br /> rcu_do_batch kernel/rcu/tree.c:2605 [inline]<br /> rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861<br /> handle_softirqs+0x286/0x870 kernel/softirq.c:579<br /> __do_softirq kernel/softirq.c:613 [inline]<br /> invoke_softirq kernel/softirq.c:453 [inline]<br /> __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680<br /> irq_exit_rcu+0x9/0x30 kernel/softirq.c:696<br /> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]<br /> sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Silence warning when chunk allocation fails in trace_pid_write<br /> <br /> Syzkaller trigger a fault injection warning:<br /> <br /> WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0<br /> Tainted: [U]=USER<br /> Hardware name: Google Compute Engine/Google Compute Engine<br /> RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294<br /> Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff<br /> RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283<br /> RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000<br /> RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef<br /> R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0<br /> FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464<br /> register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]<br /> register_pid_events kernel/trace/trace_events.c:2354 [inline]<br /> event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425<br /> vfs_write+0x24c/0x1150 fs/read_write.c:677<br /> ksys_write+0x12b/0x250 fs/read_write.c:731<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> We can reproduce the warning by following the steps below:<br /> 1. echo 8 &gt;&gt; set_event_notrace_pid. Let tr-&gt;filtered_pids owns one pid<br /> and register sched_switch tracepoint.<br /> 2. echo &amp;#39; &amp;#39; &gt;&gt; set_event_pid, and perform fault injection during chunk<br /> allocation of trace_pid_list_alloc. Let pid_list with no pid and<br /> assign to tr-&gt;filtered_pids.<br /> 3. echo &amp;#39; &amp;#39; &gt;&gt; set_event_pid. Let pid_list is NULL and assign to<br /> tr-&gt;filtered_pids.<br /> 4. echo 9 &gt;&gt; set_event_pid, will trigger the double register<br /> sched_switch tracepoint warning.<br /> <br /> The reason is that syzkaller injects a fault into the chunk allocation<br /> in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which<br /> may trigger double register of the same tracepoint. This only occurs<br /> when the system is about to crash, but to suppress this warning, let&amp;#39;s<br /> add failure handling logic to trace_pid_list_set.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()<br /> <br /> When creating a new scheme of DAMON_RECLAIM, the calculation of<br /> &amp;#39;min_age_region&amp;#39; uses &amp;#39;aggr_interval&amp;#39; as the divisor, which may lead to<br /> division-by-zero errors. Fix it by directly returning -EINVAL when such a<br /> case occurs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of_numa: fix uninitialized memory nodes causing kernel panic<br /> <br /> When there are memory-only nodes (nodes without CPUs), these nodes are not<br /> properly initialized, causing kernel panic during boot.<br /> <br /> of_numa_init<br /> of_numa_parse_cpu_nodes<br /> node_set(nid, numa_nodes_parsed);<br /> of_numa_parse_memory_nodes<br /> <br /> In of_numa_parse_cpu_nodes, numa_nodes_parsed gets updated only for nodes<br /> containing CPUs. Memory-only nodes should have been updated in<br /> of_numa_parse_memory_nodes, but they weren&amp;#39;t.<br /> <br /> Subsequently, when free_area_init() attempts to access NODE_DATA() for<br /> these uninitialized memory nodes, the kernel panics due to NULL pointer<br /> dereference.<br /> <br /> This can be reproduced on ARM64 QEMU with 1 CPU and 2 memory nodes:<br /> <br /> qemu-system-aarch64 \<br /> -cpu host -nographic \<br /> -m 4G -smp 1 \<br /> -machine virt,accel=kvm,gic-version=3,iommu=smmuv3 \<br /> -object memory-backend-ram,size=2G,id=mem0 \<br /> -object memory-backend-ram,size=2G,id=mem1 \<br /> -numa node,nodeid=0,memdev=mem0 \<br /> -numa node,nodeid=1,memdev=mem1 \<br /> -kernel $IMAGE \<br /> -hda $DISK \<br /> -append "console=ttyAMA0 root=/dev/vda rw earlycon"<br /> <br /> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x481fd010]<br /> [ 0.000000] Linux version 6.17.0-rc1-00001-gabb4b3daf18c-dirty (yintirui@local) (gcc (GCC) 12.3.1, GNU ld (GNU Binutils) 2.41) #52 SMP PREEMPT Mon Aug 18 09:49:40 CST 2025<br /> [ 0.000000] KASLR enabled<br /> [ 0.000000] random: crng init done<br /> [ 0.000000] Machine model: linux,dummy-virt<br /> [ 0.000000] efi: UEFI not found.<br /> [ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options &amp;#39;&amp;#39;)<br /> [ 0.000000] printk: legacy bootconsole [pl11] enabled<br /> [ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT<br /> [ 0.000000] NODE_DATA(0) allocated [mem 0xbfffd9c0-0xbfffffff]<br /> [ 0.000000] node 1 must be removed before remove section 23<br /> [ 0.000000] Zone ranges:<br /> [ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff]<br /> [ 0.000000] DMA32 empty<br /> [ 0.000000] Normal [mem 0x0000000100000000-0x000000013fffffff]<br /> [ 0.000000] Movable zone start for each node<br /> [ 0.000000] Early memory node ranges<br /> [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000bfffffff]<br /> [ 0.000000] node 1: [mem 0x00000000c0000000-0x000000013fffffff]<br /> [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff]<br /> [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0<br /> [ 0.000000] Mem abort info:<br /> [ 0.000000] ESR = 0x0000000096000004<br /> [ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 0.000000] SET = 0, FnV = 0<br /> [ 0.000000] EA = 0, S1PTW = 0<br /> [ 0.000000] FSC = 0x04: level 0 translation fault<br /> [ 0.000000] Data abort info:<br /> [ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 0.000000] [00000000000000a0] user address but active_mm is swapper<br /> [ 0.000000] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc1-00001-g760c6dabf762-dirty #54 PREEMPT<br /> [ 0.000000] Hardware name: linux,dummy-virt (DT)<br /> [ 0.000000] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.000000] pc : free_area_init+0x50c/0xf9c<br /> [ 0.000000] lr : free_area_init+0x5c0/0xf9c<br /> [ 0.000000] sp : ffffa02ca0f33c00<br /> [ 0.000000] x29: ffffa02ca0f33cb0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 0.000000] x26: 4ec4ec4ec4ec4ec5 x25: 00000000000c0000 x24: 00000000000c0000<br /> [ 0.000000] x23: 0000000000040000 x22: 0000000000000000 x21: ffffa02ca0f3b368<br /> [ 0.000000] x20: ffffa02ca14c7b98 x19: 0000000000000000 x18: 0000000000000002<br /> [ 0.000000] x17: 000000000000cacc x16: 0000000000000001 x15: 0000000000000001<br /> [ 0.000000] x14: 0000000080000000 x13: 0000000000000018 x12: 0000000000000002<br /> [ 0.0<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: kexec: initialize kexec_buf struct in load_other_segments()<br /> <br /> Patch series "kexec: Fix invalid field access".<br /> <br /> The kexec_buf structure was previously declared without initialization. <br /> commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")<br /> added a field that is always read but not consistently populated by all<br /> architectures. This un-initialized field will contain garbage.<br /> <br /> This is also triggering a UBSAN warning when the uninitialized data was<br /> accessed:<br /> <br /> ------------[ cut here ]------------<br /> UBSAN: invalid-load in ./include/linux/kexec.h:210:10<br /> load of value 252 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> <br /> Zero-initializing kexec_buf at declaration ensures all fields are cleanly<br /> set, preventing future instances of uninitialized memory being used.<br /> <br /> An initial fix was already landed for arm64[0], and this patchset fixes<br /> the problem on the remaining arm64 code and on riscv, as raised by Mark.<br /> <br /> Discussions about this problem could be found at[1][2].<br /> <br /> <br /> This patch (of 3):<br /> <br /> The kexec_buf structure was previously declared without initialization.<br /> commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")<br /> added a field that is always read but not consistently populated by all<br /> architectures. This un-initialized field will contain garbage.<br /> <br /> This is also triggering a UBSAN warning when the uninitialized data was<br /> accessed:<br /> <br /> ------------[ cut here ]------------<br /> UBSAN: invalid-load in ./include/linux/kexec.h:210:10<br /> load of value 252 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> <br /> Zero-initializing kexec_buf at declaration ensures all fields are<br /> cleanly set, preventing future instances of uninitialized memory being<br /> used.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phylink: add lock for serializing concurrent pl-&gt;phydev writes with resolver<br /> <br /> Currently phylink_resolve() protects itself against concurrent<br /> phylink_bringup_phy() or phylink_disconnect_phy() calls which modify<br /> pl-&gt;phydev by relying on pl-&gt;state_mutex.<br /> <br /> The problem is that in phylink_resolve(), pl-&gt;state_mutex is in a lock<br /> inversion state with pl-&gt;phydev-&gt;lock. So pl-&gt;phydev-&gt;lock needs to be<br /> acquired prior to pl-&gt;state_mutex. But that requires dereferencing<br /> pl-&gt;phydev in the first place, and without pl-&gt;state_mutex, that is<br /> racy.<br /> <br /> Hence the reason for the extra lock. Currently it is redundant, but it<br /> will serve a functional purpose once mutex_lock(&amp;phy-&gt;lock) will be<br /> moved outside of the mutex_lock(&amp;pl-&gt;state_mutex) section.<br /> <br /> Another alternative considered would have been to let phylink_resolve()<br /> acquire the rtnl_mutex, which is also held when phylink_bringup_phy()<br /> and phylink_disconnect_phy() are called. But since phylink_disconnect_phy()<br /> runs under rtnl_lock(), it would deadlock with phylink_resolve() when<br /> calling flush_work(&amp;pl-&gt;resolve). Additionally, it would have been<br /> undesirable because it would have unnecessarily blocked many other call<br /> paths as well in the entire kernel, so the smaller-scoped lock was<br /> preferred.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: remove oem i2c adapter on finish<br /> <br /> Fixes a bug where unbinding of the GPU would leave the oem i2c adapter<br /> registered resulting in a null pointer dereference when applications try<br /> to access the invalid device.<br /> <br /> (cherry picked from commit 89923fb7ead4fdd37b78dd49962d9bb5892403e6)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dev_ioctl: take ops lock in hwtstamp lower paths<br /> <br /> ndo hwtstamp callbacks are expected to run under the per-device ops<br /> lock. Make the lower get/set paths consistent with the rest of ndo<br /> invocations.<br /> <br /> Kernel log:<br /> WARNING: CPU: 13 PID: 51364 at ./include/net/netdev_lock.h:70 __netdev_update_features+0x4bd/0xe60<br /> ...<br /> RIP: 0010:__netdev_update_features+0x4bd/0xe60<br /> ...<br /> Call Trace:<br /> <br /> netdev_update_features+0x1f/0x60<br /> mlx5_hwtstamp_set+0x181/0x290 [mlx5_core]<br /> mlx5e_hwtstamp_set+0x19/0x30 [mlx5_core]<br /> dev_set_hwtstamp_phylib+0x9f/0x220<br /> dev_set_hwtstamp_phylib+0x9f/0x220<br /> dev_set_hwtstamp+0x13d/0x240<br /> dev_ioctl+0x12f/0x4b0<br /> sock_ioctl+0x171/0x370<br /> __x64_sys_ioctl+0x3f7/0x900<br /> ? __sys_setsockopt+0x69/0xb0<br /> do_syscall_64+0x6f/0x2e0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> ...<br /> <br /> ....<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Note that the mlx5_hwtstamp_set and mlx5e_hwtstamp_set functions shown<br /> in the trace come from an in progress patch converting the legacy ioctl<br /> to ndo_hwtstamp_get/set and are not present in mainline.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()<br /> <br /> kasan_populate_vmalloc() and its helpers ignore the caller&amp;#39;s gfp_mask and<br /> always allocate memory using the hardcoded GFP_KERNEL flag. This makes<br /> them inconsistent with vmalloc(), which was recently extended to support<br /> GFP_NOFS and GFP_NOIO allocations.<br /> <br /> Page table allocations performed during shadow population also ignore the<br /> external gfp_mask. To preserve the intended semantics of GFP_NOFS and<br /> GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate<br /> memalloc scope.<br /> <br /> xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.<br /> <br /> There was a report here<br /> https://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.com<br /> <br /> This patch:<br /> - Extends kasan_populate_vmalloc() and helpers to take gfp_mask;<br /> - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page();<br /> - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore()<br /> around apply_to_page_range();<br /> - Updates vmalloc.c and percpu allocator call sites accordingly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer<br /> <br /> Avoid below overlapping mappings by using a contiguous<br /> non-cacheable buffer.<br /> <br /> [ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST,<br /> overlapping mappings aren&amp;#39;t supported<br /> [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300<br /> [ 4.097071] Modules linked in:<br /> [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1<br /> [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT)<br /> [ 4.118824] Workqueue: events_unbound deferred_probe_work_func<br /> [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 4.131624] pc : add_dma_entry+0x23c/0x300<br /> [ 4.135658] lr : add_dma_entry+0x23c/0x300<br /> [ 4.139792] sp : ffff800009dbb490<br /> [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000<br /> [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8<br /> [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20<br /> [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006<br /> [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e<br /> [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec<br /> [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58<br /> [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000<br /> [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40<br /> [ 4.214185] Call trace:<br /> [ 4.216605] add_dma_entry+0x23c/0x300<br /> [ 4.220338] debug_dma_map_sg+0x198/0x350<br /> [ 4.224373] __dma_map_sg_attrs+0xa0/0x110<br /> [ 4.228411] dma_map_sg_attrs+0x10/0x2c<br /> [ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc<br /> [ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174<br /> [ 4.242127] nand_read_oob+0x1d4/0x8e0<br /> [ 4.245861] mtd_read_oob_std+0x58/0x84<br /> [ 4.249596] mtd_read_oob+0x90/0x150<br /> [ 4.253231] mtd_read+0x68/0xac

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()<br /> <br /> Patch series "mm/damon: avoid divide-by-zero in DAMON module&amp;#39;s parameters<br /> application".<br /> <br /> DAMON&amp;#39;s RECLAIM and LRU_SORT modules perform no validation on<br /> user-configured parameters during application, which may lead to<br /> division-by-zero errors.<br /> <br /> Avoid the divide-by-zero by adding validation checks when DAMON modules<br /> attempt to apply the parameters.<br /> <br /> <br /> This patch (of 2):<br /> <br /> During the calculation of &amp;#39;hot_thres&amp;#39; and &amp;#39;cold_thres&amp;#39;, either<br /> &amp;#39;sample_interval&amp;#39; or &amp;#39;aggr_interval&amp;#39; is used as the divisor, which may<br /> lead to division-by-zero errors. Fix it by directly returning -EINVAL<br /> when such a case occurs. Additionally, since &amp;#39;aggr_interval&amp;#39; is already<br /> required to be set no smaller than &amp;#39;sample_interval&amp;#39; in damon_set_attrs(),<br /> only the case where &amp;#39;sample_interval&amp;#39; is zero needs to be checked.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.