Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: altmodes/displayport: validate count before reading Status Update VDO<br /> <br /> A broken/malicious device can send the incorrect count for a status<br /> update VDO, which will cause the kernel to read uninitialized stack data<br /> and send it off elsewhere.<br /> <br /> Fix this up by correctly verifying the count for the update object.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes()<br /> <br /> svdm_consume_modes() checks pmdata-&gt;altmodes against the array size once<br /> before the loop over the count, but forgot to check the bound at every<br /> point in the loop.<br /> <br /> In the well-behaved SVDM discovery flow this is harmless because each of<br /> at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX<br /> modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX]. But the<br /> CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming<br /> ACK with any request the port actually sent. Once port-&gt;partner is set,<br /> an unsolicited Discover Modes ACK is consumed unconditionally. A broken<br /> or malicious port partner can therefore drive altmodes to<br /> ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra<br /> Discover Modes ACK with seven VDOs. Because the pre-loop check passes,<br /> the loop could then writes up to five entries past altmode_desc[]. For<br /> mode_data_prime the next field in struct tcpm_port is the<br /> partner_altmode[] pointer array, which then receives partner-chosen<br /> SVID/VDO bytes.<br /> <br /> Move the bound check inside the loop so the array can never be indexed<br /> past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner<br /> supplies or how the function was reached.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers<br /> <br /> Properly validate the count passed from a device when calling<br /> svdm_consume_identity() or svdm_consume_identity_sop_prime() as the<br /> device-controlled value could index off of the static arrays, which<br /> could leak data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: ccg: reject firmware images without a &amp;#39;:&amp;#39; record header<br /> <br /> do_flash() locates the first .cyacd record with<br /> <br /> p = strnchr(fw-&gt;data, fw-&gt;size, &amp;#39;:&amp;#39;);<br /> while (p

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: pressure: bmp280: fix stack leak in bmp580 trigger handler<br /> <br /> bmp580_trigger_handler() declares its scan buffer on the stack without<br /> an initializer and then memcpy()s 3 bytes of 24-bit sensor data into<br /> each 4-byte __le32 field. The high byte of comp_temp and comp_press is<br /> left uninitialized, and the channel storagebits is 32, so two bytes of<br /> stack are pushed to userspace per scan.<br /> <br /> This is a regression from when the buffer lived in the private data, the<br /> move to a stack-local struct dropped the implicit zeroing.<br /> bme280_trigger_handler() was fixed up to handle this bug, but this<br /> driver was not fixed because there was no padding hole, but rather a<br /> short-fill issue.<br /> <br /> Fix this all by just zero-initializing the structure on the stack.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: adis16550: fix stack leak in trigger handler<br /> <br /> adis16550_trigger_handler() declares the scan data array on the stack<br /> without initializing it. The memcpy() at the bottom fills only the<br /> first 28 bytes (TEMP + 6 channels of GYRO/ACCEL data), and<br /> iio_push_to_buffers_with_timestamp() writes the s64 timestamp at the<br /> 8-byte-aligned offset 32. Bytes 28-31 remain uninitialized stack data<br /> which leaks to userspace on ever trigger.<br /> <br /> Fix this all by just zero-initializing the structure on the stack.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer<br /> <br /> The tagged FIFO path declares iio_buff on the stack with __aligned(8)<br /> but no initializer, but there is a hole in the structure, which will<br /> then leak to userspace as ST_LSM6DSX_SAMPLE_SIZE bytes (6) will be<br /> copied, but the space between that and the timestamp are not<br /> initialized.<br /> <br /> Commit c14edb4d0bdc ("iio:imu:st_lsm6dsx Fix alignment and data leak<br /> issues") moved the untagged FIFO path to a kzalloc&amp;#39;d buffer in hw-&gt;scan,<br /> but for the tagged path it only added the alignment qualifier and not<br /> the initializer :(<br /> <br /> Fix this by just zero-initializing the structure on the stack.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix possible infinite loop in fib6_select_path()<br /> <br /> Found while auditing the same pattern Sashiko reported in<br /> rt6_fill_node() [1]. Apply the same fix as<br /> commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").<br /> <br /> Writers holding tb6_lock can list_del_rcu(&amp;first-&gt;fib6_siblings)<br /> without waiting for RCU readers; first-&gt;fib6_siblings.next then<br /> still points into the old ring and this softirq-side walker never<br /> reaches &amp;first-&gt;fib6_siblings as its terminator. fib6_purge_rt()<br /> always WRITE_ONCE()s first-&gt;fib6_nsiblings to 0 before<br /> list_del_rcu(), so an inside-loop check is a reliable detach signal.<br /> <br /> [1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix possible infinite loop in rt6_fill_node()<br /> <br /> Sashiko reported this issue [1]. Apply the same fix as<br /> commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").<br /> <br /> Writers holding tb6_lock can list_del_rcu(&amp;rt-&gt;fib6_siblings)<br /> without waiting for RCU readers; rt-&gt;fib6_siblings.next then still<br /> points into the old ring and this softirq-side walker never reaches<br /> &amp;rt-&gt;fib6_siblings, causing a CPU stall. fib6_del_route() always<br /> WRITE_ONCE()s rt-&gt;fib6_nsiblings to 0 before list_del_rcu(), so an<br /> inside-loop check is a reliable detach signal.<br /> <br /> [1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/migrate_device: fix pgtable leak in migrate_vma_insert_huge_pmd_page<br /> <br /> When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due<br /> to a PMD check failure, the pgtable allocated earlier via<br /> pte_alloc_one() is never freed, causing a memory leak.<br /> <br /> Added free_abort label to release the pgtable in error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hpfs: fix a crash if hpfs_map_dnode_bitmap fails<br /> <br /> If hpfs_map_dnode_bitmap fails, the code would call hpfs_brelse4 on<br /> uninitialized quad buffer head, causing a crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: do not trigger BUG() on BH disabled context<br /> <br /> __get_vm_area_node() currently triggers a BUG() if in_interrupt() returns<br /> true. However, in_interrupt() also reports true when BH are disabled.<br /> <br /> The bridge code can call rhashtable_lookup_insert_fast() with bottom<br /> halves disabled:<br /> <br /> __vlan_add()<br /> -&gt; br_fdb_add_local()<br /> spin_lock_bh(&amp;br-&gt;hash_lock); fdb_add_local()<br /> -&gt; fdb_create()<br /> -&gt; rhashtable_lookup_insert_fast()<br /> -&gt; kvmalloc()<br /> -&gt; vmalloc()<br /> -&gt; __get_vm_area_node()<br /> -&gt; BUG_ON(in_interrupt())<br /> spin_unlock_bh(&amp;br-&gt;hash_lock)<br /> <br /> this triggers the BUG() despite the caller not being in NMI or<br /> hard IRQ context.<br /> <br /> Replace the in_interrupt() check with in_nmi() || in_hardirq().