Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: da9063: fix null pointer deref with partial DT config<br /> <br /> When some of the da9063 regulators do not have corresponding DT nodes<br /> a null pointer dereference occurs on boot because such regulators have<br /> no init_data causing the pointers calculated in<br /> da9063_check_xvp_constraints() to be invalid.<br /> <br /> Do not dereference them in this case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda/ca0132: fixup buffer overrun at tuning_ctl_set()<br /> <br /> tuning_ctl_set() might have buffer overrun at (X) if it didn&amp;#39;t break<br /> from loop by matching (A).<br /> <br /> static int tuning_ctl_set(...)<br /> {<br /> for (i = 0; i

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Improve page fault error reporting<br /> <br /> If IOMMU domain for device group is not setup properly then we may hit<br /> IOMMU page fault. Current page fault handler assumes that domain is<br /> always setup and it will hit NULL pointer derefence (see below sample log).<br /> <br /> Lets check whether domain is setup or not and log appropriate message.<br /> <br /> Sample log:<br /> ----------<br /> amdgpu 0000:00:01.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 6<br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 2 PID: 56 Comm: irq/24-AMD-Vi Not tainted 6.2.0-rc2+ #89<br /> Hardware name: xxx<br /> RIP: 0010:report_iommu_fault+0x11/0x90<br /> [...]<br /> Call Trace:<br /> <br /> amd_iommu_int_thread+0x60c/0x760<br /> ? __pfx_irq_thread_fn+0x10/0x10<br /> irq_thread_fn+0x1f/0x60<br /> irq_thread+0xea/0x1a0<br /> ? preempt_count_add+0x6a/0xa0<br /> ? __pfx_irq_thread_dtor+0x10/0x10<br /> ? __pfx_irq_thread+0x10/0x10<br /> kthread+0xe9/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> <br /> [joro: Edit commit message]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Zeroing allocated object from slab in bpf memory allocator<br /> <br /> Currently the freed element in bpf memory allocator may be immediately<br /> reused, for htab map the reuse will reinitialize special fields in map<br /> value (e.g., bpf_spin_lock), but lookup procedure may still access<br /> these special fields, and it may lead to hard-lockup as shown below:<br /> <br /> NMI backtrace for cpu 16<br /> CPU: 16 PID: 2574 Comm: htab.bin Tainted: G L 6.1.0+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> RIP: 0010:queued_spin_lock_slowpath+0x283/0x2c0<br /> ......<br /> Call Trace:<br /> <br /> copy_map_value_locked+0xb7/0x170<br /> bpf_map_copy_value+0x113/0x3c0<br /> __sys_bpf+0x1c67/0x2780<br /> __x64_sys_bpf+0x1c/0x20<br /> do_syscall_64+0x30/0x60<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> ......<br /> <br /> <br /> For htab map, just like the preallocated case, these is no need to<br /> initialize these special fields in map value again once these fields<br /> have been initialized. For preallocated htab map, these fields are<br /> initialized through __GFP_ZERO in bpf_map_area_alloc(), so do the<br /> similar thing for non-preallocated htab in bpf memory allocator. And<br /> there is no need to use __GFP_ZERO for per-cpu bpf memory allocator,<br /> because __alloc_percpu_gfp() does it implicitly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix warning for holder mismatch from export_rdev()<br /> <br /> Commit a1d767191096 ("md: use mddev-&gt;external to select holder in<br /> export_rdev()") fix the problem that &amp;#39;claim_rdev&amp;#39; is used for<br /> blkdev_get_by_dev() while &amp;#39;rdev&amp;#39; is used for blkdev_put().<br /> <br /> However, if mddev-&gt;external is changed from 0 to 1, then &amp;#39;rdev&amp;#39; is used<br /> for blkdev_get_by_dev() while &amp;#39;claim_rdev&amp;#39; is used for blkdev_put(). And<br /> this problem can be reporduced reliably by following:<br /> <br /> New file: mdadm/tests/23rdev-lifetime<br /> <br /> devname=${dev0##*/}<br /> devt=`cat /sys/block/$devname/dev`<br /> pid=""<br /> runtime=2<br /> <br /> clean_up_test() {<br /> pill -9 $pid<br /> echo clear &gt; /sys/block/md0/md/array_state<br /> }<br /> <br /> trap &amp;#39;clean_up_test&amp;#39; EXIT<br /> <br /> add_by_sysfs() {<br /> while true; do<br /> echo $devt &gt; /sys/block/md0/md/new_dev<br /> done<br /> }<br /> <br /> remove_by_sysfs(){<br /> while true; do<br /> echo remove &gt; /sys/block/md0/md/dev-${devname}/state<br /> done<br /> }<br /> <br /> echo md0 &gt; /sys/module/md_mod/parameters/new_array || die "create md0 failed"<br /> <br /> add_by_sysfs &amp;<br /> pid="$pid $!"<br /> <br /> remove_by_sysfs &amp;<br /> pid="$pid $!"<br /> <br /> sleep $runtime<br /> exit 0<br /> <br /> Test cmd:<br /> <br /> ./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime<br /> <br /> Test result:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 960 at block/bdev.c:618 blkdev_put+0x27c/0x330<br /> Modules linked in: multipath md_mod loop<br /> CPU: 0 PID: 960 Comm: test Not tainted 6.5.0-rc2-00121-g01e55c376936-dirty #50<br /> RIP: 0010:blkdev_put+0x27c/0x330<br /> Call Trace:<br /> <br /> export_rdev.isra.23+0x50/0xa0 [md_mod]<br /> mddev_unlock+0x19d/0x300 [md_mod]<br /> rdev_attr_store+0xec/0x190 [md_mod]<br /> sysfs_kf_write+0x52/0x70<br /> kernfs_fop_write_iter+0x19a/0x2a0<br /> vfs_write+0x3b5/0x770<br /> ksys_write+0x74/0x150<br /> __x64_sys_write+0x22/0x30<br /> do_syscall_64+0x40/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Fix the problem by recording if &amp;#39;rdev&amp;#39; is used as holder.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-core: fix memory leak in dhchap_ctrl_secret<br /> <br /> Free dhchap_secret in nvme_ctrl_dhchap_ctrl_secret_store() before we<br /> return when nvme_auth_generate_key() returns error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf tool x86: Fix perf_env memory leak<br /> <br /> Found by leak sanitizer:<br /> ```<br /> ==1632594==ERROR: LeakSanitizer: detected memory leaks<br /> <br /> Direct leak of 21 byte(s) in 1 object(s) allocated from:<br /> #0 0x7f2953a7077b in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:439<br /> #1 0x556701d6fbbf in perf_env__read_cpuid util/env.c:369<br /> #2 0x556701d70589 in perf_env__cpuid util/env.c:465<br /> #3 0x55670204bba2 in x86__is_amd_cpu arch/x86/util/env.c:14<br /> #4 0x5567020487a2 in arch__post_evsel_config arch/x86/util/evsel.c:83<br /> #5 0x556701d8f78b in evsel__config util/evsel.c:1366<br /> #6 0x556701ef5872 in evlist__config util/record.c:108<br /> #7 0x556701cd6bcd in test__PERF_RECORD tests/perf-record.c:112<br /> #8 0x556701cacd07 in run_test tests/builtin-test.c:236<br /> #9 0x556701cacfac in test_and_print tests/builtin-test.c:265<br /> #10 0x556701cadddb in __cmd_test tests/builtin-test.c:402<br /> #11 0x556701caf2aa in cmd_test tests/builtin-test.c:559<br /> #12 0x556701d3b557 in run_builtin tools/perf/perf.c:323<br /> #13 0x556701d3bac8 in handle_internal_command tools/perf/perf.c:377<br /> #14 0x556701d3be90 in run_argv tools/perf/perf.c:421<br /> #15 0x556701d3c3f8 in main tools/perf/perf.c:537<br /> #16 0x7f2952a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58<br /> <br /> SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s).<br /> ```

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix session state check in reconnect to avoid use-after-free issue<br /> <br /> Don&amp;#39;t collect exiting session in smb2_reconnect_server(), because it<br /> will be released soon.<br /> <br /> Note that the exiting session will stay in server-&gt;smb_ses_list until<br /> it complete the cifs_free_ipc() and logoff() and then delete itself<br /> from the list.

*** 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 /> drm/amd/display: fix FCLK pstate change underflow<br /> <br /> [Why]<br /> Currently we set FCLK p-state change<br /> watermark calculated based on dummy<br /> p-state latency when UCLK p-state is<br /> not supported<br /> <br /> [How]<br /> Calculate FCLK p-state change watermark<br /> based on on FCLK pstate change latency<br /> in case UCLK p-state is not supported

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc: Fix use-after-free in tcp_write_timer_handler().<br /> <br /> With Eric&amp;#39;s ref tracker, syzbot finally found a repro for<br /> use-after-free in tcp_write_timer_handler() by kernel TCP<br /> sockets. [0]<br /> <br /> If SMC creates a kernel socket in __smc_create(), the kernel<br /> socket is supposed to be freed in smc_clcsock_release() by<br /> calling sock_release() when we close() the parent SMC socket.<br /> <br /> However, at the end of smc_clcsock_release(), the kernel<br /> socket&amp;#39;s sk_state might not be TCP_CLOSE. This means that<br /> we have not called inet_csk_destroy_sock() in __tcp_close()<br /> and have not stopped the TCP timers.<br /> <br /> The kernel socket&amp;#39;s TCP timers can be fired later, so we<br /> need to hold a refcnt for net as we do for MPTCP subflows<br /> in mptcp_subflow_create_socket().<br /> <br /> [0]:<br /> leaked reference.<br /> sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108)<br /> inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244)<br /> __sock_create (net/socket.c:1546)<br /> smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284)<br /> __sock_create (net/socket.c:1546)<br /> __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661)<br /> __x64_sys_socket (net/socket.c:1672)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)<br /> Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091<br /> <br /> CPU: 0 PID: 18091 Comm: syzrepro Tainted: G W 6.3.0-rc4-01174-gb5d54eb5899a #7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:107)<br /> print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)<br /> kasan_report (mm/kasan/report.c:538)<br /> tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)<br /> tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643)<br /> call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)<br /> __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022)<br /> run_timer_softirq (kernel/time/timer.c:2037)<br /> __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572)<br /> __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650)<br /> irq_exit_rcu (kernel/softirq.c:664)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dccp: Fix out of bounds access in DCCP error handler<br /> <br /> There was a previous attempt to fix an out-of-bounds access in the DCCP<br /> error handlers, but that fix assumed that the error handlers only want<br /> to access the first 8 bytes of the DCCP header. Actually, they also look<br /> at the DCCP sequence number, which is stored beyond 8 bytes, so an<br /> explicit pskb_may_pull() is required.