Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix memory leak in binder_init()<br /> <br /> In binder_init(), the destruction of binder_alloc_shrinker_init() is not<br /> performed in the wrong path, which will cause memory leaks. So this commit<br /> introduces binder_alloc_shrinker_exit() and calls it in the wrong path to<br /> fix that.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix data-race around unix_tot_inflight.<br /> <br /> unix_tot_inflight is changed under spin_lock(unix_gc_lock), but<br /> unix_release_sock() reads it locklessly.<br /> <br /> Let&amp;#39;s use READ_ONCE() for unix_tot_inflight.<br /> <br /> Note that the writer side was marked by commit 9d6d7f1cb67c ("af_unix:<br /> annote lockless accesses to unix_tot_inflight &amp; gc_in_progress")<br /> <br /> BUG: KCSAN: data-race in unix_inflight / unix_release_sock<br /> <br /> write (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1:<br /> unix_inflight+0x130/0x180 net/unix/scm.c:64<br /> unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123<br /> unix_scm_to_skb net/unix/af_unix.c:1832 [inline]<br /> unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg+0x148/0x160 net/socket.c:747<br /> ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493<br /> ___sys_sendmsg+0xc6/0x140 net/socket.c:2547<br /> __sys_sendmsg+0x94/0x140 net/socket.c:2576<br /> __do_sys_sendmsg net/socket.c:2585 [inline]<br /> __se_sys_sendmsg net/socket.c:2583 [inline]<br /> __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> read to 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0:<br /> unix_release_sock+0x608/0x910 net/unix/af_unix.c:671<br /> unix_release+0x59/0x80 net/unix/af_unix.c:1058<br /> __sock_release+0x7d/0x170 net/socket.c:653<br /> sock_close+0x19/0x30 net/socket.c:1385<br /> __fput+0x179/0x5e0 fs/file_table.c:321<br /> ____fput+0x15/0x20 fs/file_table.c:349<br /> task_work_run+0x116/0x1a0 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:171 [inline]<br /> exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]<br /> syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297<br /> do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> value changed: 0x00000000 -&gt; 0x00000001<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmci_host: fix a race condition in vmci_host_poll() causing GPF<br /> <br /> During fuzzing, a general protection fault is observed in<br /> vmci_host_poll().<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf]<br /> RIP: 0010:__lock_acquire+0xf3/0x5e00 kernel/locking/lockdep.c:4926<br /> <br /> Call Trace:<br /> <br /> lock_acquire+0x1a4/0x4a0 kernel/locking/lockdep.c:5672<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0xb3/0x100 kernel/locking/spinlock.c:162<br /> add_wait_queue+0x3d/0x260 kernel/sched/wait.c:22<br /> poll_wait include/linux/poll.h:49 [inline]<br /> vmci_host_poll+0xf8/0x2b0 drivers/misc/vmw_vmci/vmci_host.c:174<br /> vfs_poll include/linux/poll.h:88 [inline]<br /> do_pollfd fs/select.c:873 [inline]<br /> do_poll fs/select.c:921 [inline]<br /> do_sys_poll+0xc7c/0x1aa0 fs/select.c:1015<br /> __do_sys_ppoll fs/select.c:1121 [inline]<br /> __se_sys_ppoll+0x2cc/0x330 fs/select.c:1101<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Example thread interleaving that causes the general protection fault<br /> is as follows:<br /> <br /> CPU1 (vmci_host_poll) CPU2 (vmci_host_do_init_context)<br /> ----- -----<br /> // Read uninitialized context<br /> context = vmci_host_dev-&gt;context;<br /> // Initialize context<br /> vmci_host_dev-&gt;context = vmci_ctx_create();<br /> vmci_host_dev-&gt;ct_type = VMCIOBJ_CONTEXT;<br /> <br /> if (vmci_host_dev-&gt;ct_type == VMCIOBJ_CONTEXT) {<br /> // Dereferencing the wrong pointer<br /> poll_wait(..., &amp;context-&gt;host_context);<br /> }<br /> <br /> In this scenario, vmci_host_poll() reads vmci_host_dev-&gt;context first,<br /> and then reads vmci_host_dev-&gt;ct_type to check that<br /> vmci_host_dev-&gt;context is initialized. However, since these two reads<br /> are not atomically executed, there is a chance of a race condition as<br /> described above.<br /> <br /> To fix this race condition, read vmci_host_dev-&gt;context after checking<br /> the value of vmci_host_dev-&gt;ct_type so that vmci_host_poll() always<br /> reads an initialized context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_vdpa: build affinity masks conditionally<br /> <br /> We try to build affinity mask via create_affinity_masks()<br /> unconditionally which may lead several issues:<br /> <br /> - the affinity mask is not used for parent without affinity support<br /> (only VDUSE support the affinity now)<br /> - the logic of create_affinity_masks() might not work for devices<br /> other than block. For example it&amp;#39;s not rare in the networking device<br /> where the number of queues could exceed the number of CPUs. Such<br /> case breaks the current affinity logic which is based on<br /> group_cpus_evenly() who assumes the number of CPUs are not less than<br /> the number of groups. This can trigger a warning[1]:<br /> <br /> if (ret &gt;= 0)<br /> WARN_ON(nr_present + nr_others

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: cadence: cdns_i2c_master_xfer(): Fix runtime PM leak on error path<br /> <br /> The cdns_i2c_master_xfer() function gets a runtime PM reference when the<br /> function is entered. This reference is released when the function is<br /> exited. There is currently one error path where the function exits<br /> directly, which leads to a leak of the runtime PM reference.<br /> <br /> Make sure that this error path also releases the runtime PM reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: ACPICA: check null return of ACPI_ALLOCATE_ZEROED in acpi_db_display_objects<br /> <br /> ACPICA commit 0d5f467d6a0ba852ea3aad68663cbcbd43300fd4<br /> <br /> ACPI_ALLOCATE_ZEROED may fails, object_info might be null and will cause<br /> null pointer dereference later.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Disallow unallocated resources to be returned<br /> <br /> In the event that the topology requests resources that have not been<br /> created by the system (because they are typically not represented in<br /> dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC<br /> blocks, until their allocation/assignment is being sanity-checked in<br /> "drm/msm/dpu: Reject topologies for which no DSC blocks are available")<br /> remain NULL but will still be returned out of<br /> dpu_rm_get_assigned_resources, where the caller expects to get an array<br /> containing num_blks valid pointers (but instead gets these NULLs).<br /> <br /> To prevent this from happening, where null-pointer dereferences<br /> typically result in a hard-to-debug platform lockup, num_blks shouldn&amp;#39;t<br /> increase past NULL blocks and will print an error and break instead.<br /> After all, max_blks represents the static size of the maximum number of<br /> blocks whereas the actual amount varies per platform.<br /> <br /> ^1: which can happen after a git rebase ended up moving additions to<br /> _dpu_cfg to a different struct which has the same patch context.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/517636/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: ocb: don&amp;#39;t leave if not joined<br /> <br /> If there&amp;#39;s no OCB state, don&amp;#39;t ask the driver/mac80211 to<br /> leave, since that&amp;#39;s just confusing. Since set/clear the<br /> chandef state, that&amp;#39;s a simple check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y<br /> <br /> After a pci_doe_task completes, its work_struct needs to be destroyed<br /> to avoid a memory leak with CONFIG_DEBUG_OBJECTS=y.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: remove WARN_ON to prevent panic_on_warn<br /> <br /> Remove unnecessary early code development check and the WARN_ON<br /> that it uses. The irq alloc and free paths have long been<br /> cleaned up and this check shouldn&amp;#39;t have stuck around so long.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: fix one memleak in __inet_del_ifa()<br /> <br /> I got the below warning when do fuzzing test:<br /> unregister_netdevice: waiting for bond0 to become free. Usage count = 2<br /> <br /> It can be repoduced via:<br /> <br /> ip link add bond0 type bond<br /> sysctl -w net.ipv4.conf.bond0.promote_secondaries=1<br /> ip addr add 4.117.174.103/0 scope 0x40 dev bond0<br /> ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0<br /> ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0<br /> ip addr del 4.117.174.103/0 scope 0x40 dev bond0<br /> ip link delete bond0 type bond<br /> <br /> In this reproduction test case, an incorrect &amp;#39;last_prim&amp;#39; is found in<br /> __inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)<br /> is lost. The memory of the secondary address is leaked and the reference of<br /> in_device and net_device is leaked.<br /> <br /> Fix this problem:<br /> Look for &amp;#39;last_prim&amp;#39; starting at location of the deleted IP and inserting<br /> the promoted IP into the location of &amp;#39;last_prim&amp;#39;.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/sev: Make enc_dec_hypercall() accept a size instead of npages<br /> <br /> enc_dec_hypercall() accepted a page count instead of a size, which<br /> forced its callers to round up. As a result, non-page aligned<br /> vaddrs caused pages to be spuriously marked as decrypted via the<br /> encryption status hypercall, which in turn caused consistent<br /> corruption of pages during live migration. Live migration requires<br /> accurate encryption status information to avoid migrating pages<br /> from the wrong perspective.