Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objects<br /> <br /> If a badly constructed firmware includes multiple `ACPI_TYPE_PACKAGE`<br /> objects while evaluating the AMD LPS0 _DSM, there will be a memory<br /> leak. Explicitly guard against this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Handle race between rb_move_tail and rb_check_pages<br /> <br /> It seems a data race between ring_buffer writing and integrity check.<br /> That is, RB_FLAG of head_page is been updating, while at same time<br /> RB_FLAG was cleared when doing integrity check rb_check_pages():<br /> <br /> rb_check_pages() rb_handle_head_page():<br /> -------- --------<br /> rb_head_page_deactivate()<br /> rb_head_page_set_normal()<br /> rb_head_page_activate()<br /> <br /> We do intergrity test of the list to check if the list is corrupted and<br /> it is still worth doing it. So, let&amp;#39;s refactor rb_check_pages() such that<br /> we no longer clear and set flag during the list sanity checking.<br /> <br /> [1] and [2] are the test to reproduce and the crash report respectively.<br /> <br /> 1:<br /> ``` read_trace.sh<br /> while true;<br /> do<br /> # the "trace" file is closed after read<br /> head -1 /sys/kernel/tracing/trace &gt; /dev/null<br /> done<br /> ```<br /> ``` repro.sh<br /> sysctl -w kernel.panic_on_warn=1<br /> # function tracer will writing enough data into ring_buffer<br /> echo function &gt; /sys/kernel/tracing/current_tracer<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ```<br /> <br /> 2:<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 9 PID: 62 at kernel/trace/ring_buffer.c:2653<br /> rb_move_tail+0x450/0x470<br /> Modules linked in:<br /> CPU: 9 PID: 62 Comm: ksoftirqd/9 Tainted: G W 6.2.0-rc6+<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:rb_move_tail+0x450/0x470<br /> Code: ff ff 4c 89 c8 f0 4d 0f b1 02 48 89 c2 48 83 e2 fc 49 39 d0 75 24<br /> 83 e0 03 83 f8 02 0f 84 e1 fb ff ff 48 8b 57 10 f0 ff 42 08 0b 83<br /> f8 02 0f 84 ce fb ff ff e9 db<br /> RSP: 0018:ffffb5564089bd00 EFLAGS: 00000203<br /> RAX: 0000000000000000 RBX: ffff9db385a2bf81 RCX: ffffb5564089bd18<br /> RDX: ffff9db281110100 RSI: 0000000000000fe4 RDI: ffff9db380145400<br /> RBP: ffff9db385a2bf80 R08: ffff9db385a2bfc0 R09: ffff9db385a2bfc2<br /> R10: ffff9db385a6c000 R11: ffff9db385a2bf80 R12: 0000000000000000<br /> R13: 00000000000003e8 R14: ffff9db281110100 R15: ffffffffbb006108<br /> FS: 0000000000000000(0000) GS:ffff9db3bdcc0000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005602323024c8 CR3: 0000000022e0c000 CR4: 00000000000006e0<br /> Call Trace:<br /> <br /> ring_buffer_lock_reserve+0x136/0x360<br /> ? __do_softirq+0x287/0x2df<br /> ? __pfx_rcu_softirq_qs+0x10/0x10<br /> trace_function+0x21/0x110<br /> ? __pfx_rcu_softirq_qs+0x10/0x10<br /> ? __do_softirq+0x287/0x2df<br /> function_trace_call+0xf6/0x120<br /> 0xffffffffc038f097<br /> ? rcu_softirq_qs+0x5/0x140<br /> rcu_softirq_qs+0x5/0x140<br /> __do_softirq+0x287/0x2df<br /> run_ksoftirqd+0x2a/0x30<br /> smpboot_thread_fn+0x188/0x220<br /> ? __pfx_smpboot_thread_fn+0x10/0x10<br /> kthread+0xe7/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [ crash report and test reproducer credit goes to Zheng Yejian]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix error code of return in mt7921_acpi_read<br /> <br /> Kernel NULL pointer dereference when ACPI SAR table isn&amp;#39;t implemented well.<br /> Fix the error code of return to mark the ACPI SAR table as invalid.<br /> <br /> [ 5.077128] mt7921e 0000:06:00.0: sar cnt = 0<br /> [ 5.077381] BUG: kernel NULL pointer dereference, address:<br /> 0000000000000004<br /> [ 5.077630] #PF: supervisor read access in kernel mode<br /> [ 5.077883] #PF: error_code(0x0000) - not-present page<br /> [ 5.078138] PGD 0 P4D 0<br /> [ 5.078398] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 5.079202] RIP: 0010:mt7921_init_acpi_sar+0x106/0x220<br /> [mt7921_common]<br /> ...<br /> [ 5.080786] Call Trace:<br /> [ 5.080786] <br /> [ 5.080786] mt7921_register_device+0x37d/0x490 [mt7921_common]<br /> [ 5.080786] mt7921_pci_probe.part.0+0x2ee/0x310 [mt7921e]<br /> [ 5.080786] mt7921_pci_probe+0x52/0x70 [mt7921e]<br /> [ 5.080786] local_pci_probe+0x47/0x90<br /> [ 5.080786] pci_call_probe+0x55/0x190<br /> [ 5.080786] pci_device_probe+0x84/0x120

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix a potential data corruption<br /> <br /> We must ensure that the subrequests are joined back into the head before<br /> we can retransmit a request. If the head was not on the commit lists,<br /> because the server wrote it synchronously, we still need to add it back<br /> to the retransmission list.<br /> Add a call that mirrors the effect of nfs_cancel_remove_inode() for<br /> O_DIRECT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9317/1: kexec: Make smp stop calls asynchronous<br /> <br /> If a panic is triggered by a hrtimer interrupt all online cpus will be<br /> notified and set offline. But as highlighted by commit 19dbdcb8039c<br /> ("smp: Warn on function calls from softirq context") this call should<br /> not be made synchronous with disabled interrupts:<br /> <br /> softdog: Initiating panic<br /> Kernel panic - not syncing: Software Watchdog Timer expired<br /> WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond<br /> unwind_backtrace:<br /> show_stack<br /> dump_stack_lvl<br /> __warn<br /> warn_slowpath_fmt<br /> smp_call_function_many_cond<br /> smp_call_function<br /> crash_smp_send_stop.part.0<br /> machine_crash_shutdown<br /> __crash_kexec<br /> panic<br /> softdog_fire<br /> __hrtimer_run_queues<br /> hrtimer_interrupt<br /> <br /> Make the smp call for machine_crash_nonpanic_core() asynchronous.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: sme: Use STR P to clear FFR context field in streaming SVE mode<br /> <br /> The FFR is a predicate register which can vary between 16 and 256 bits<br /> in size depending upon the configured vector length. When saving the<br /> SVE state in streaming SVE mode, the FFR register is inaccessible and<br /> so commit 9f5848665788 ("arm64/sve: Make access to FFR optional") simply<br /> clears the FFR field of the in-memory context structure. Unfortunately,<br /> it achieves this using an unconditional 8-byte store and so if the SME<br /> vector length is anything other than 64 bytes in size we will either<br /> fail to clear the entire field or, worse, we will corrupt memory<br /> immediately following the structure. This has led to intermittent kfence<br /> splats in CI [1] and can trigger kmalloc Redzone corruption messages<br /> when running the &amp;#39;fp-stress&amp;#39; kselftest:<br /> <br /> | =============================================================================<br /> | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten<br /> | -----------------------------------------------------------------------------<br /> |<br /> | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc<br /> | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531<br /> | __kmalloc+0x8c/0xcc<br /> | do_sme_acc+0x9c/0x220<br /> | ...<br /> <br /> Replace the 8-byte store with a store of a predicate register which has<br /> been zero-initialised with PFALSE, ensuring that the entire field is<br /> cleared in memory.<br /> <br /> [1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Detect system inodes linked into directory hierarchy<br /> <br /> When UDF filesystem is corrupted, hidden system inodes can be linked<br /> into directory hierarchy which is an avenue for further serious<br /> corruption of the filesystem and kernel confusion as noticed by syzbot<br /> fuzzed images. Refuse to access system inodes linked into directory<br /> hierarchy and vice versa.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()<br /> <br /> There is a memory leak reported by kmemleak:<br /> <br /> unreferenced object 0xffffc900003f0000 (size 12288):<br /> comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __vmalloc_node_range+0xe56/0x1110<br /> [] __vmalloc_node+0xbd/0x150<br /> [] vmalloc+0x25/0x30<br /> [] qla2x00_create_host+0x7a0/0xe30 [qla2xxx]<br /> [] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx]<br /> [] local_pci_probe+0xeb/0x1a0<br /> <br /> The root cause is traced to an error-handling path in qla2x00_probe_one()<br /> when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" is<br /> used to record the port information and it is allocated in<br /> qla2x00_create_host(). However, it is not released in the error handling<br /> path "probe_failed".<br /> <br /> Fix this by freeing the memory of "scan.l" when an error occurs in the<br /> adapter initialization process.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()<br /> <br /> Memory pointed by &amp;#39;nd_pmu-&gt;pmu.attr_groups&amp;#39; is allocated in function<br /> &amp;#39;register_nvdimm_pmu&amp;#39; and is lost after &amp;#39;kfree(nd_pmu)&amp;#39; call in function<br /> &amp;#39;unregister_nvdimm_pmu&amp;#39;.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: fix refcount underflow in error path<br /> <br /> Fix a refcount underflow problem reported by syzbot that can happen<br /> when a system is running out of memory. If xp_alloc_tx_descs() fails,<br /> and it can only fail due to not having enough memory, then the error<br /> path is triggered. In this error path, the refcount of the pool is<br /> decremented as it has incremented before. However, the reference to<br /> the pool in the socket was not nulled. This means that when the socket<br /> is closed later, the socket teardown logic will think that there is a<br /> pool attached to the socket and try to decrease the refcount again,<br /> leading to a refcount underflow.<br /> <br /> I chose this fix as it involved adding just a single line. Another<br /> option would have been to move xp_get_pool() and the assignment of<br /> xs-&gt;pool to after the if-statement and using xs_umem-&gt;pool instead of<br /> xs-&gt;pool in the whole if-statement resulting in somewhat simpler code,<br /> but this would have led to much more churn in the code base perhaps<br /> making it harder to backport.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: move memblock_allow_resize() after linear mapping is ready<br /> <br /> The initial memblock metadata is accessed from kernel image mapping. The<br /> regions arrays need to "reallocated" from memblock and accessed through<br /> linear mapping to cover more memblock regions. So the resizing should<br /> not be allowed until linear mapping is ready. Note that there are<br /> memblock allocations when building linear mapping.<br /> <br /> This patch is similar to 24cc61d8cb5a ("arm64: memblock: don&amp;#39;t permit<br /> memblock resizing until linear mapping is up").<br /> <br /> In following log, many memblock regions are reserved before<br /> create_linear_mapping_page_table(). And then it triggered reallocation<br /> of memblock.reserved.regions and memcpy the old array in kernel image<br /> mapping to the new array in linear mapping which caused a page fault.<br /> <br /> [ 0.000000] memblock_reserve: [0x00000000bf01f000-0x00000000bf01ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf021000-0x00000000bf021fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf023000-0x00000000bf023fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf025000-0x00000000bf025fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf027000-0x00000000bf027fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf029000-0x00000000bf029fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf02b000-0x00000000bf02bfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf02d000-0x00000000bf02dfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf02f000-0x00000000bf02ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf030000-0x00000000bf030fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] OF: reserved mem: 0x0000000080000000..0x000000008007ffff (512 KiB) map non-reusable mmode_resv0@80000000<br /> [ 0.000000] memblock_reserve: [0x00000000bf000000-0x00000000bf001fed] paging_init+0x19a/0x5ae<br /> [ 0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c<br /> [ 0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128<br /> [ 0.000000] memblock: reserved is doubled to 256 at [0x000000017fffd000-0x000000017fffe7ff]<br /> [ 0.000000] Unable to handle kernel paging request at virtual address ff600000ffffd000<br /> [ 0.000000] Oops [#1]<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.0-rc1-00011-g99a670b2069c #66<br /> [ 0.000000] Hardware name: riscv-virtio,qemu (DT)<br /> [ 0.000000] epc : __memcpy+0x60/0xf8<br /> [ 0.000000] ra : memblock_double_array+0x192/0x248<br /> [ 0.000000] epc : ffffffff8081d214 ra : ffffffff80a3dfc0 sp : ffffffff81403bd0<br /> [ 0.000000] gp : ffffffff814fbb38 tp : ffffffff8140dac0 t0 : 0000000001600000<br /> [ 0.000000] t1 : 0000000000000000 t2 : 000000008f001000 s0 : ffffffff81403c60<br /> [ 0.000000] s1 : ffffffff80c0bc98 a0 : ff600000ffffd000 a1 : ffffffff80c0bcd8<br /> [ 0.000000] a2 : 0000000000000c00 a3 : ffffffff80c0c8d8 a4 : 0000000080000000<br /> [ 0.000000] a5 : 0000000000080000 a6 : 0000000000000000 a7 : 0000000080200000<br /> [ 0.000000] s2 : ff600000ffffd000 s3 : 0000000000002000 s4 : 0000000000000c00<br /> [ 0.000000] s5 : ffffffff80c0bc60 s6 : ffffffff80c0bcc8 s7 : 0000000000000000<br /> [ 0.000000] s8 : ffffffff814fd0a8 s9 : 000000017fffe7ff s10: 0000000000000000<br /> [ 0.000000] s11: 0000000000001000 t3 : 0000000000001000 t4 : 0000000000000000<br /> [ 0.000000] t5 : 000000008f003000 t6 : ff600000ffffd000<br /> [ 0.000000] status: 0000000200000100 badaddr: ff600000ffffd000 cause: 000000000000000f<br /> [ 0.000000] [

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: max9286: Fix memleak in max9286_v4l2_register()<br /> <br /> There is a kmemleak when testing the media/i2c/max9286.c with bpf mock<br /> device:<br /> <br /> kmemleak: 5 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> <br /> unreferenced object 0xffff88810defc400 (size 256):<br /> comm "python3", pid 278, jiffies 4294737563 (age 31.978s)<br /> hex dump (first 32 bytes):<br /> 28 06 a7 0a 81 88 ff ff 00 fe 22 12 81 88 ff ff (.........".....<br /> 10 c4 ef 0d 81 88 ff ff 10 c4 ef 0d 81 88 ff ff ................<br /> backtrace:<br /> [] __kmalloc_node+0x44/0x1b0<br /> [] kvmalloc_node+0x34/0x180<br /> [] v4l2_ctrl_new+0x325/0x10f0 [videodev]<br /> [] v4l2_ctrl_new_std+0x16f/0x210 [videodev]<br /> [] max9286_probe+0x76e/0xbff [max9286]<br /> [] i2c_device_probe+0x28d/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x359/0x4f0<br /> [] of_i2c_register_device+0xf1/0x110<br /> <br /> max9286_v4l2_register() calls v4l2_ctrl_new_std(), but won&amp;#39;t free the<br /> created v412_ctrl when fwnode_graph_get_endpoint_by_id() failed, which<br /> causes the memleak. Call v4l2_ctrl_handler_free() to free the v412_ctrl.