Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix out-of-bounds access in ipv6_find_tlv()<br /> <br /> optlen is fetched without checking whether there is more than one byte to parse.<br /> It can lead to out-of-bounds access.<br /> <br /> Found by InfoTeCS on behalf of Linux Verification Center<br /> (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmemmap/devdax: fix kernel crash when probing devdax devices<br /> <br /> commit 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for<br /> compound devmaps") added support for using optimized vmmemap for devdax<br /> devices. But how vmemmap mappings are created are architecture specific. <br /> For example, powerpc with hash translation doesn&amp;#39;t have vmemmap mappings<br /> in init_mm page table instead they are bolted table entries in the<br /> hardware page table<br /> <br /> vmemmap_populate_compound_pages() used by vmemmap optimization code is not<br /> aware of these architecture-specific mapping. Hence allow architecture to<br /> opt for this feature. I selected architectures supporting<br /> HUGETLB_PAGE_OPTIMIZE_VMEMMAP option as also supporting this feature.<br /> <br /> This patch fixes the below crash on ppc64.<br /> <br /> BUG: Unable to handle kernel data access on write at 0xc00c000100400038<br /> Faulting instruction address: 0xc000000001269d90<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in:<br /> CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc5-150500.34-default+ #2 5c90a668b6bbd142599890245c2fb5de19d7d28a<br /> Hardware name: IBM,9009-42G POWER9 (raw) 0x4e0202 0xf000005 of:IBM,FW950.40 (VL950_099) hv:phyp pSeries<br /> NIP: c000000001269d90 LR: c0000000004c57d4 CTR: 0000000000000000<br /> REGS: c000000003632c30 TRAP: 0300 Not tainted (6.3.0-rc5-150500.34-default+)<br /> MSR: 8000000000009033 CR: 24842228 XER: 00000000<br /> CFAR: c0000000004c57d0 DAR: c00c000100400038 DSISR: 42000000 IRQMASK: 0<br /> ....<br /> NIP [c000000001269d90] __init_single_page.isra.74+0x14/0x4c<br /> LR [c0000000004c57d4] __init_zone_device_page+0x44/0xd0<br /> Call Trace:<br /> [c000000003632ed0] [c000000003632f60] 0xc000000003632f60 (unreliable)<br /> [c000000003632f10] [c0000000004c5ca0] memmap_init_zone_device+0x170/0x250<br /> [c000000003632fe0] [c0000000005575f8] memremap_pages+0x2c8/0x7f0<br /> [c0000000036330c0] [c000000000557b5c] devm_memremap_pages+0x3c/0xa0<br /> [c000000003633100] [c000000000d458a8] dev_dax_probe+0x108/0x3e0<br /> [c0000000036331a0] [c000000000d41430] dax_bus_probe+0xb0/0x140<br /> [c0000000036331d0] [c000000000cef27c] really_probe+0x19c/0x520<br /> [c000000003633260] [c000000000cef6b4] __driver_probe_device+0xb4/0x230<br /> [c0000000036332e0] [c000000000cef888] driver_probe_device+0x58/0x120<br /> [c000000003633320] [c000000000cefa6c] __device_attach_driver+0x11c/0x1e0<br /> [c0000000036333a0] [c000000000cebc58] bus_for_each_drv+0xa8/0x130<br /> [c000000003633400] [c000000000ceefcc] __device_attach+0x15c/0x250<br /> [c0000000036334a0] [c000000000ced458] bus_probe_device+0x108/0x110<br /> [c0000000036334f0] [c000000000ce92dc] device_add+0x7fc/0xa10<br /> [c0000000036335b0] [c000000000d447c8] devm_create_dev_dax+0x1d8/0x530<br /> [c000000003633640] [c000000000d46b60] __dax_pmem_probe+0x200/0x270<br /> [c0000000036337b0] [c000000000d46bf0] dax_pmem_probe+0x20/0x70<br /> [c0000000036337d0] [c000000000d2279c] nvdimm_bus_probe+0xac/0x2b0<br /> [c000000003633860] [c000000000cef27c] really_probe+0x19c/0x520<br /> [c0000000036338f0] [c000000000cef6b4] __driver_probe_device+0xb4/0x230<br /> [c000000003633970] [c000000000cef888] driver_probe_device+0x58/0x120<br /> [c0000000036339b0] [c000000000cefd08] __driver_attach+0x1d8/0x240<br /> [c000000003633a30] [c000000000cebb04] bus_for_each_dev+0xb4/0x130<br /> [c000000003633a90] [c000000000cee564] driver_attach+0x34/0x50<br /> [c000000003633ab0] [c000000000ced878] bus_add_driver+0x218/0x300<br /> [c000000003633b40] [c000000000cf1144] driver_register+0xa4/0x1b0<br /> [c000000003633bb0] [c000000000d21a0c] __nd_driver_register+0x5c/0x100<br /> [c000000003633c10] [c00000000206a2e8] dax_pmem_init+0x34/0x48<br /> [c000000003633c30] [c0000000000132d0] do_one_initcall+0x60/0x320<br /> [c000000003633d00] [c0000000020051b0] kernel_init_freeable+0x360/0x400<br /> [c000000003633de0] [c000000000013764] kernel_init+0x34/0x1d0<br /> [c000000003633e50] [c00000000000de14] ret_from_kernel_thread+0x5c/0x64

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1<br /> <br /> The type of size is unsigned int, if size is 0x40000000, there will<br /> be an integer overflow, size will be zero after size *= sizeof(uint32_t),<br /> will cause uninitialized memory to be referenced later.

*** 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 *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** 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.