Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Fix use-after-free of CPU job query arrays on error path<br /> <br /> The CPU job ioctl&amp;#39;s fail label calls kvfree() on cpu_job&amp;#39;s timestamp and<br /> performance query arrays after v3d_job_cleanup(), which drops the job&amp;#39;s<br /> last reference and frees cpu_job. Reading cpu_job at that point is a<br /> use-after-free. Also, on the early v3d_job_init() failure path, it is a<br /> NULL dereference, since v3d_job_deallocate() zeroes the local pointer.<br /> <br /> In the success path, the arrays are released from the scheduler&amp;#39;s<br /> .free_job callback, but on the error path, they are freed manually, as<br /> the job was never pushed to the scheduler. While the success path deals<br /> with this correctly, the fail path doesn&amp;#39;t.<br /> <br /> On top of that, the manual kvfree() calls only free the array storage;<br /> they don&amp;#39;t drm_syncobj_put() the per-query syncobjs that<br /> v3d_timestamp_query_info_free() and v3d_performance_query_info_free()<br /> release on the success path. So the same fail path that triggers the<br /> use-after-free also leaks one syncobj reference per query.<br /> <br /> Unify the CPU job teardown into the CPU job&amp;#39;s kref destructor, mirroring<br /> v3d_render_job_free(). The scheduler&amp;#39;s .free_job slot reverts to the<br /> generic v3d_sched_job_free() and the fail label drops the manual<br /> kvfree() calls, leaving a single teardown path that is reached from both<br /> the scheduler and the ioctl error path. That removes the use-after-free,<br /> the NULL dereference, and the syncobj leak by construction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Validate GPIO pin LUT table size before iterating<br /> <br /> [Why&amp;How]<br /> The GPIO pin table parsers in get_gpio_i2c_info() and<br /> bios_parser_get_gpio_pin_info() derive an element count from the VBIOS<br /> table_header.structuresize field, then iterate over gpio_pin[] entries.<br /> However, GET_IMAGE() only validates that the table header itself fits<br /> within the BIOS image. If the VBIOS reports a structuresize larger than<br /> the actual mapped data, the loop reads past the end of the BIOS image,<br /> causing an out-of-bounds read.<br /> <br /> Fix this by calling bios_get_image() to validate that the full claimed<br /> structuresize is accessible within the BIOS image before entering the<br /> loop in both functions.<br /> <br /> (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR<br /> <br /> adm1266_gpio_get_multiple() iterates the PDIO portion of the<br /> caller-supplied mask using<br /> <br /> for_each_set_bit_from(gpio_nr, mask,<br /> ADM1266_GPIO_NR + ADM1266_PDIO_STATUS) {<br /> ...<br /> }<br /> <br /> where ADM1266_PDIO_STATUS is the PMBus command code (0xE9, i.e. 233),<br /> not the number of PDIO pins. The intended upper bound is<br /> ADM1266_GPIO_NR + ADM1266_PDIO_NR = 25.<br /> <br /> gpiolib hands in a mask sized for gc.ngpio (= 25 bits on this chip),<br /> so the iteration walks find_next_bit() up to 242, reading up to 217<br /> extra bits (a handful of unsigned-long words: four on 64-bit, seven<br /> on 32-bit) of whatever lives past the end of the mask in the<br /> caller&amp;#39;s stack. Any incidental set bit in that range then drives a<br /> set_bit(gpio_nr, bits) call that writes past the end of the<br /> caller-supplied bits array too -- both out-of-bounds.<br /> <br /> Substitute ADM1266_PDIO_NR for the constant so the scan stops at the<br /> last real PDIO bit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer<br /> <br /> adm1266_pmbus_block_xfer() copies the device-supplied block payload<br /> into the caller-provided buffer using the device-supplied length:<br /> <br /> memcpy(data_r, &amp;msgs[1].buf[1], msgs[1].buf[0]);<br /> <br /> The helper does not know how large data_r is and trusts the device to<br /> return at most one record&amp;#39;s worth of bytes. adm1266_nvmem_read_blackbox()<br /> violates that contract: it advances read_buff inside data-&gt;dev_mem in<br /> ADM1266_BLACKBOX_SIZE (64-byte) strides while the helper is willing to<br /> write up to ADM1266_PMBUS_BLOCK_MAX (255) bytes. A device that returns<br /> more than 64 bytes on the trailing record (read_buff offset 1984 in<br /> the 2048-byte dev_mem allocation) overflows dev_mem by up to 191 bytes<br /> before the post-call<br /> <br /> if (ret != ADM1266_BLACKBOX_SIZE)<br /> return -EIO;<br /> <br /> can reject the response.<br /> <br /> Contain the fix in the caller without changing the helper signature:<br /> read each record into a 255-byte local bounce buffer that matches the<br /> helper&amp;#39;s maximum output, validate the returned length, and only then<br /> copy exactly ADM1266_BLACKBOX_SIZE bytes into the dev_mem slot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer<br /> <br /> adm1266_pmbus_block_xfer() sets up the read transaction with<br /> <br /> .buf = data-&gt;read_buf,<br /> .len = ADM1266_PMBUS_BLOCK_MAX + 2,<br /> <br /> but read_buf in struct adm1266_data is declared as<br /> <br /> u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1];<br /> <br /> For a max-length block response (length byte = 255 + up to 1 PEC<br /> byte), the i2c controller is told to write 257 bytes into a 256-byte<br /> buffer, putting one byte past the end of read_buf. The same response<br /> also makes the subsequent PEC compare<br /> <br /> if (crc != msgs[1].buf[msgs[1].buf[0] + 1])<br /> <br /> read a byte beyond the array.<br /> <br /> Bump the read_buf declaration to ADM1266_PMBUS_BLOCK_MAX + 2 so the<br /> buffer can hold the length byte, up to 255 payload bytes, and the PEC<br /> byte the i2c_msg length already accounts for.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) reject implausible blackbox record_count<br /> <br /> adm1266_nvmem_read_blackbox() loops over a record_count that comes<br /> straight from byte 3 of the BLACKBOX_INFO response. The destination<br /> buffer is data-&gt;dev_mem, sized for the nvmem cell&amp;#39;s declared 2048<br /> bytes (ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64).<br /> A device that reports a record_count greater than 32 -- whether due<br /> to firmware bugs, bus corruption, or a non-responsive slave returning<br /> 0xff -- would walk read_buff past the end of the dev_mem allocation<br /> on the trailing iterations.<br /> <br /> Cap record_count at ADM1266_BLACKBOX_MAX_RECORDS (introduced here)<br /> before entering the loop and return -EIO on any larger value, so a<br /> malformed BLACKBOX_INFO response cannot drive the loop out of bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tt: fix negative tt_buff_len<br /> <br /> batadv_orig_node::tt_buff_len was declared as s16, but the field is never<br /> intended to hold a negative value. When a value greater than 32767 is<br /> assigned, it wraps to a negative signed integer.<br /> <br /> In batadv_send_other_tt_response(), tt_buff_len is temporarily widened to<br /> s32. The incorrectly negative s16 value propagates into the s32, causing<br /> batadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but<br /> populates only a small portion of it with the collected changeset. All<br /> remaining bits are kept uninitialized.<br /> <br /> Using an u16 avoids this type confusion and ensures that no (negative) sign<br /> extension is performed in batadv_send_other_tt_response().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tt: fix negative last_changeset_len<br /> <br /> batadv_piv_tt::last_changeset_len len was declared as s16, but the field is<br /> never intended to hold a negative value. When a value greater than 32767 is<br /> assigned, it wraps to a negative signed integer.<br /> <br /> In batadv_send_my_tt_response(), last_changeset_len is temporarily widened<br /> to s32. The incorrectly negative s16 value propagates into the s32, causing<br /> batadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but<br /> populates only a small portion of it with the collected changeset. All<br /> remaining bits are kept uninitialized.<br /> <br /> Using an u16 avoids this type confusion and ensures that no (negative) sign<br /> extension is performed in batadv_send_my_tt_response().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tt: avoid empty VLAN responses<br /> <br /> The commit 16116dac2339 ("batman-adv: prevent TT request storms by not<br /> sending inconsistent TT TLVLs") added checks to the local (direct) TT<br /> response code. But the response can also be done indirectly by another node<br /> using the global TT state. To avoid such inconsistency states reported in<br /> the original fix, also avoid sending empty VLANs for replies from the<br /> global TT state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tt: fix TOCTOU race for reported vlans<br /> <br /> The local TT based TVLV is generated by first checking the number of VLANs<br /> which have at least one TT entry. A new buffer with the correct size for<br /> the VLANs is then allocated. Only then, the list of VLANs s used to fill<br /> the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock<br /> is held. But the actual number of TT entries of each VLAN can still<br /> increase during this time - just not the number of VLANs in the list.<br /> <br /> But the prefilter used in the buffer size calculation might still cause an<br /> increase of the number of VLANs which need to be stored. Simply because a<br /> VLAN might now suddenly have at least one entry when it had none in the<br /> pre-alloc check - and then needs to occupy space which was not allocated.<br /> <br /> It is better to overestimate the buffer size at the beginning and then fill<br /> the buffer only with the VLANs which are not empty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/statmount: fix slab out-of-bounds write in statmount_mnt_idmap<br /> <br /> statmount_mnt_idmap() writes one mapping with seq_printf() and then<br /> manually advances seq-&gt;count to include the NUL separator.<br /> <br /> If seq_printf() overflows, seq_set_overflow() sets seq-&gt;count to<br /> seq-&gt;size. The manual seq-&gt;count++ changes this to seq-&gt;size + 1.<br /> seq_has_overflowed() then no longer detects the overflow. The corrupted<br /> count returns to statmount_string(), which later executes:<br /> <br /> seq-&gt;buf[seq-&gt;count++] = &amp;#39;\0&amp;#39;;<br /> <br /> This causes a 1-byte NULL out-of-bounds write on the dynamically<br /> allocated seq buffer.<br /> <br /> Fix this by checking for overflow immediately after seq_printf().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fprobe: Fix unregister_fprobe() to wait for RCU grace period<br /> <br /> Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer")<br /> changed fprobe to register struct fprobe to an rcu-hlist, but it forgot<br /> to wait for RCU GP. Thus there can be use-after-free if the fprobe is<br /> released right after unregistering. This can be happened on fprobe<br /> event and sample module code.<br /> <br /> To fix this issue, add synchronize_rcu() in unregister_fprobe().<br /> <br /> Note that BPF is OK because fprobe is used as a part of<br /> bpf_kprobe_multi_link. This unregisters its fprobe in<br /> bpf_kprobe_multi_link_release() and it is deallocated via<br /> bpf_kprobe_multi_link_dealloc(), which is invoked from<br /> bpf_link_defer_dealloc_rcu_gp() RCU callback.<br /> <br /> For BPF, this also introduced unregister_fprobe_async() which does<br /> NOT wait for RCU grace priod.