Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/kbuf: check if target buffer list is still legacy on recycle<br /> <br /> There&amp;#39;s a gap between when the buffer was grabbed and when it<br /> potentially gets recycled, where if the list is empty, someone could&amp;#39;ve<br /> upgraded it to a ring provided type. This can happen if the request<br /> is forced via io-wq. The legacy recycling is missing checking if the<br /> buffer_list still exists, and if it&amp;#39;s of the correct type. Add those<br /> checks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix a few more NULL pointer dereference in device cleanup<br /> <br /> I found a few more paths that cleanup fails due to a NULL version pointer<br /> on unsupported hardware.<br /> <br /> Add NULL checks as applicable.<br /> <br /> (cherry picked from commit f5a05f8414fc10f307eb965f303580c7778f8dd2)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix potential overflow of shmem scatterlist length<br /> <br /> When a scatterlists table of a GEM shmem object of size 4 GB or more is<br /> populated with pages allocated from a folio, unsigned int .length<br /> attribute of a scatterlist may get overflowed if total byte length of<br /> pages allocated to that single scatterlist happens to reach or cross the<br /> 4GB limit. As a consequence, users of the object may suffer from hitting<br /> unexpected, premature end of the object&amp;#39;s backing pages.<br /> <br /> [278.780187] ------------[ cut here ]------------<br /> [278.780377] WARNING: CPU: 1 PID: 2326 at drivers/gpu/drm/i915/i915_mm.c:55 remap_sg+0x199/0x1d0 [i915]<br /> ...<br /> [278.780654] CPU: 1 UID: 0 PID: 2326 Comm: gem_mmap_offset Tainted: G S U 6.17.0-rc1-CI_DRM_16981-ged823aaa0607+ #1 PREEMPT(voluntary)<br /> [278.780656] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER<br /> [278.780658] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024<br /> [278.780659] RIP: 0010:remap_sg+0x199/0x1d0 [i915]<br /> ...<br /> [278.780786] Call Trace:<br /> [278.780787] <br /> [278.780788] ? __apply_to_page_range+0x3e6/0x910<br /> [278.780795] ? __pfx_remap_sg+0x10/0x10 [i915]<br /> [278.780906] apply_to_page_range+0x14/0x30<br /> [278.780908] remap_io_sg+0x14d/0x260 [i915]<br /> [278.781013] vm_fault_cpu+0xd2/0x330 [i915]<br /> [278.781137] __do_fault+0x3a/0x1b0<br /> [278.781140] do_fault+0x322/0x640<br /> [278.781143] __handle_mm_fault+0x938/0xfd0<br /> [278.781150] handle_mm_fault+0x12c/0x300<br /> [278.781152] ? lock_mm_and_find_vma+0x4b/0x760<br /> [278.781155] do_user_addr_fault+0x2d6/0x8e0<br /> [278.781160] exc_page_fault+0x96/0x2c0<br /> [278.781165] asm_exc_page_fault+0x27/0x30<br /> ...<br /> <br /> That issue was apprehended by the author of a change that introduced it,<br /> and potential risk even annotated with a comment, but then never addressed.<br /> <br /> When adding folio pages to a scatterlist table, take care of byte length<br /> of any single scatterlist not exceeding max_segment.<br /> <br /> (cherry picked from commit 06249b4e691a75694c014a61708c007fb5755f60)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix NULL pointer dereference in device cleanup<br /> <br /> When GPU initialization fails due to an unsupported HW block<br /> IP blocks may have a NULL version pointer. During cleanup in<br /> amdgpu_device_fini_hw, the code calls amdgpu_device_set_pg_state and<br /> amdgpu_device_set_cg_state which iterate over all IP blocks and access<br /> adev-&gt;ip_blocks[i].version without NULL checks, leading to a kernel<br /> NULL pointer dereference.<br /> <br /> Add NULL checks for adev-&gt;ip_blocks[i].version in both<br /> amdgpu_device_set_cg_state and amdgpu_device_set_pg_state to prevent<br /> dereferencing NULL pointers during GPU teardown when initialization has<br /> failed.<br /> <br /> (cherry picked from commit b7ac77468cda92eecae560b05f62f997a12fe2f2)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: mipi-i3c-hci: Fix race in DMA ring dequeue<br /> <br /> The HCI DMA dequeue path (hci_dma_dequeue_xfer()) may be invoked for<br /> multiple transfers that timeout around the same time. However, the<br /> function is not serialized and can race with itself.<br /> <br /> When a timeout occurs, hci_dma_dequeue_xfer() stops the ring, processes<br /> incomplete transfers, and then restarts the ring. If another timeout<br /> triggers a parallel call into the same function, the two instances may<br /> interfere with each other - stopping or restarting the ring at unexpected<br /> times.<br /> <br /> Add a mutex so that hci_dma_dequeue_xfer() is serialized with respect to<br /> itself.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: proximity: hx9023s: Protect against division by zero in set_samp_freq<br /> <br /> Avoid division by zero when sampling frequency is unspecified.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: bh1780: fix PM runtime leak on error path<br /> <br /> Move pm_runtime_put_autosuspend() before the error check to ensure<br /> the PM runtime reference count is always decremented after<br /> pm_runtime_get_sync(), regardless of whether the read operation<br /> succeeds or fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: adis: Fix NULL pointer dereference in adis_init<br /> <br /> The adis_init() function dereferences adis-&gt;ops to check if the<br /> individual function pointers (write, read, reset) are NULL, but does<br /> not first check if adis-&gt;ops itself is NULL.<br /> <br /> Drivers like adis16480, adis16490, adis16545 and others do not set<br /> custom ops and rely on adis_init() assigning the defaults. Since struct<br /> adis is zero-initialized by devm_iio_device_alloc(), adis-&gt;ops is NULL<br /> when adis_init() is called, causing a NULL pointer dereference:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> pc : adis_init+0xc0/0x118<br /> Call trace:<br /> adis_init+0xc0/0x118<br /> adis16480_probe+0xe0/0x670<br /> <br /> Fix this by checking if adis-&gt;ops is NULL before dereferencing it,<br /> falling through to assign the default ops in that case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: mpu3050-core: fix pm_runtime error handling<br /> <br /> The return value of pm_runtime_get_sync() is not checked, allowing<br /> the driver to access hardware that may fail to resume. The device<br /> usage count is also unconditionally incremented. Use<br /> pm_runtime_resume_and_get() which propagates errors and avoids<br /> incrementing the usage count on failure.<br /> <br /> In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate()<br /> failure since postdisable does not run when preenable fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: add missing RCU unlock in error path in try_release_subpage_extent_buffer()<br /> <br /> Call rcu_read_lock() before exiting the loop in<br /> try_release_subpage_extent_buffer() because there is a rcu_read_unlock()<br /> call past the loop.<br /> <br /> This has been detected by the Clang thread-safety analyzer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix transaction abort on set received ioctl due to item overflow<br /> <br /> If the set received ioctl fails due to an item overflow when attempting to<br /> add the BTRFS_UUID_KEY_RECEIVED_SUBVOL we have to abort the transaction<br /> since we did some metadata updates before.<br /> <br /> This means that if a user calls this ioctl with the same received UUID<br /> field for a lot of subvolumes, we will hit the overflow, trigger the<br /> transaction abort and turn the filesystem into RO mode. A malicious user<br /> could exploit this, and this ioctl does not even requires that a user<br /> has admin privileges (CAP_SYS_ADMIN), only that he/she owns the subvolume.<br /> <br /> Fix this by doing an early check for item overflow before starting a<br /> transaction. This is also race safe because we are holding the subvol_sem<br /> semaphore in exclusive (write) mode.<br /> <br /> A test case for fstests will follow soon.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix transaction abort on file creation due to name hash collision<br /> <br /> If we attempt to create several files with names that result in the same<br /> hash, we have to pack them in same dir item and that has a limit inherent<br /> to the leaf size. However if we reach that limit, we trigger a transaction<br /> abort and turns the filesystem into RO mode. This allows for a malicious<br /> user to disrupt a system, without the need to have administration<br /> privileges/capabilities.<br /> <br /> Reproducer:<br /> <br /> $ cat exploit-hash-collisions.sh<br /> #!/bin/bash<br /> <br /> DEV=/dev/sdi<br /> MNT=/mnt/sdi<br /> <br /> # Use smallest node size to make the test faster and require fewer file<br /> # names that result in hash collision.<br /> mkfs.btrfs -f --nodesize 4K $DEV<br /> mount $DEV $MNT<br /> <br /> # List of names that result in the same crc32c hash for btrfs.<br /> declare -a names=(<br /> &amp;#39;foobar&amp;#39;<br /> &amp;#39;%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUe_L:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC&amp;#39;<br /> &amp;#39;AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0I_l5Fnam04CGIg=8@U:Z&amp;#39;<br /> &amp;#39;CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%:hHgjhIjW5vnqWHKNP4&amp;#39;<br /> &amp;#39;ET:vk@rFU4tsvMB0$C_p=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O:&amp;#39;<br /> &amp;#39;HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38fUcNGOWvE@Mz6WBeDH_VooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7I_eOsByOkBOO&amp;#39;<br /> &amp;#39;Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq:CIgE6u7eJOjmQY5qTtxE2Rjbis9@us&amp;#39;<br /> &amp;#39;KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV5vz3IiZaPmKuLYO03-6asI9lJ_j4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F:ZhHAwyctnGy%_eujl%WPd4U2BI7qooOSr85J-C2V$LfY&amp;#39;<br /> &amp;#39;NcRfDfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAb_F%n6GAGC7fT2JFFn:c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO&amp;#39;<br /> &amp;#39;Oj42AQAEzRoTxa5OuSKIr=A_lwGMy132v4g3Pdq1GvUG9874YseIFQ6QU&amp;#39;<br /> &amp;#39;Ono7avN5GjC:_6dBJ_&amp;#39;<br /> &amp;#39;WHmN2gnmaN-9dVDy4aWo:yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtU_cfW2:%2_am&amp;#39;<br /> &amp;#39;WiFnuTEhAG9FEC6zopQmj-A-$LDQ0T3WULz%ox3UZAPybSV6v1Z$b4L_XBi4M4BMBtJZpz93r9xafpB77r:lbwvitWRyo$odnAUYlYMmU4RvgnNd--e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k&amp;#39;<br /> &amp;#39;XKyH=OsOAF3p%uziGF_ZVr$ivrvhVgD@1u%5RtrV-gl_vqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-$ZpQfCL7phxQbUcb:BZOTPaFExc-qK-gDRCDW2&amp;#39;<br /> &amp;#39;d3uUR6OFEwZr%ns1XH_@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD:JF7=h9a_43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd&amp;#39;<br /> &amp;#39;ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2Go_GQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z::ZRcv5O:lDCFm&amp;#39;<br /> &amp;#39;evqk743Y@dvZAiG5J05L_ROFV@$2%rVWJ2%3nxV72-W7$e$-SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG:$euFYmXn$_2rA9mKZ&amp;#39;<br /> &amp;#39;gkgUtnihWXsZQTEkrMAWIxir09k3t7jk_IK25t1:cy1XWN0GGqC%FrySdcmU7M8MuPO_ppkLw3=Dfr0UuBAL4%GFk2$Ma10V1jDRGJje%Xx9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky&amp;#39;<br /> &amp;#39;hNgsG_8lNRik3PvphqPm0yEH3P%%fYG:kQLY=6O-61Wa6nrV_WVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS&amp;#39;<br /> &amp;#39;isA7JVzN12xCxVPJZ_qoLm-pTBuhjjHMvV7o=F:EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz&amp;#39;<br /> &amp;#39;kiJ_fgcdZFDiOptjgH5PN9-PSyLO4fbk_:u5_2tz35lV_iXiJ6cx7pwjTtKy-XGaQ5IefmpJ4N_ZqGsqCsKuqOOBgf9LkUdffHet@Wu&amp;#39;<br /> &amp;#39;lvwtxyhE9:%Q3UxeHiViUyNzJsy:fm38pg_b6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYr_qrB49i=pA--@WqWLIuX7o1S_SfS@2FSiUZN&amp;#39;<br /> &amp;#39;rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY:Z=SLc@QLMSt2zsss2ZXrP7j4=&amp;#39;<br /> &amp;#39;uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS:lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAYbnVn&amp;#39;<br /> &amp;#39;UG37U6KKua2bgc:IHzRs7BnB6FD:2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW:mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD:R02ghwYo%yx7SAaaq-:x33LYpei$5g8DMl3C&amp;#39;<br /> &amp;#39;y2vjek0FE1PDJC0qpfnN:x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW&amp;#39;<br /> &amp;#39;8-HCSgH5B%K7P8_jaVtQhBXpBk:pE-$P7ts58U0J@iR9YZntMPl7j$s62yAJO@_9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc&amp;#39;<br /> &amp;#39;YPPh:IFt2mtR6XWSmjHptXL_hbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA_2MBwZ8Dr4=R1D%7-mC<br /> ---truncated---