Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp<br /> <br /> If dcid is received for an already-assigned destination CID the spec<br /> requires that both channels to be discarded, but calling l2cap_chan_del<br /> may invalidate the tmp cursor created by list_for_each_entry_safe and<br /> in fact it is the wrong procedure as the chan-&gt;dcid may be assigned<br /> previously it really needs to be disconnected.<br /> <br /> Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so<br /> instead schedule l2cap_chan_timeout with delay 0 to close the channel<br /> asynchronously.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: l2cap: clear chan-&gt;ident on ECRED reconfiguration success<br /> <br /> l2cap_ecred_reconf_rsp() returns early on success without clearing<br /> chan-&gt;ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp,<br /> l2cap_le_connect_rsp, l2cap_config_rsp) clears chan-&gt;ident after a<br /> successful transaction to prevent the channel from matching subsequent<br /> responses with the recycled ident value.<br /> <br /> A remote attacker that completed a reconfiguration as the peer can<br /> replay a failure response with the stale ident, causing the kernel to<br /> match and destroy the already-established channel via<br /> l2cap_chan_del(chan, ECONNRESET).<br /> <br /> Clear chan-&gt;ident for all matching channels on success, and harden the<br /> failure path by using l2cap_chan_hold_unless_zero() consistent with<br /> other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: zl3073x: use __dpll_device_change_ntf() and remove change_work<br /> <br /> The change_work was introduced to send device change notifications<br /> from DPLL device callbacks without deadlocking on dpll_lock, since<br /> the callbacks are already invoked under that lock. Now that<br /> __dpll_device_change_ntf() is exported for callers that already<br /> hold dpll_lock, use it directly and remove the change_work<br /> infrastructure entirely.<br /> <br /> This eliminates a race condition where change_work could be<br /> re-scheduled after cancel_work_sync() during device teardown,<br /> potentially causing the handler to dereference a freed or NULL<br /> dpll_dev pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: Drain pending requests at net namespace exit<br /> <br /> The arguments to list_splice_init() in handshake_net_exit() are<br /> reversed. The call moves the local empty "requests" list onto<br /> hn-&gt;hn_requests, leaving the local list empty, so the subsequent<br /> drain loop runs zero iterations. Pending handshake requests that<br /> had not yet been accepted are not torn down when the net namespace<br /> is destroyed; each one keeps a reference on a socket file and on<br /> the handshake_req allocation.<br /> <br /> Pass the source and destination in the documented order<br /> (list_splice_init(list, head) moves list onto head) so the pending<br /> list is transferred to the local scratch list and drained through<br /> handshake_complete().<br /> <br /> Fixing the splice direction exposes a list-corruption race. After<br /> the splice each req-&gt;hr_list still has non-empty link pointers,<br /> threading the stack-local scratch list rather than hn_requests.<br /> A concurrent handshake_req_cancel() -- for example, from sunrpc&amp;#39;s<br /> TLS timeout on a kernel socket whose netns reference was not<br /> taken -- finds the request through the rhashtable, calls<br /> remove_pending(), and sees !list_empty(&amp;req-&gt;hr_list).<br /> __remove_pending_locked() then list_del_init()s an entry off the<br /> scratch list while the drain iterates, corrupting it. The same<br /> call arriving after the drain loop has run list_del() on an<br /> entry hits LIST_POISON instead.<br /> <br /> Have remove_pending() check HANDSHAKE_F_NET_DRAINING under<br /> hn_lock and report not-found when drain is in progress. The<br /> drain has already taken ownership; handshake_complete()&amp;#39;s existing<br /> test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates<br /> between drain and cancel for who calls the consumer&amp;#39;s hp_done. Use<br /> list_del_init() rather than list_del() in the drain so req-&gt;hr_list<br /> does not carry LIST_POISON after drain releases the entry.<br /> <br /> The DRAINING guard in remove_pending() makes cancel return false,<br /> but cancel still falls through to test_and_set_bit on<br /> HANDSHAKE_F_REQ_COMPLETED and drops the request&amp;#39;s hr_file reference.<br /> Without another pin, if that is the last reference, sk_destruct frees<br /> the request while it is still linked on the drain loop&amp;#39;s local list.<br /> Pin each request&amp;#39;s hr_file under hn_lock before releasing the list,<br /> and drop that drain pin after the loop finishes with the request.

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.

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.

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.

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

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.

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.

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.

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