<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v6.1.178</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.178</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.178'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-07-24T13:55:19+00:00</updated>
<entry>
<title>Linux 6.1.178</title>
<updated>2026-07-24T13:55:19+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2026-07-24T13:55:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc5c83b7f5f83ea99aea5c771b1ec77458263a15'/>
<id>urn:sha1:dc5c83b7f5f83ea99aea5c771b1ec77458263a15</id>
<content type='text'>
Link: https://lore.kernel.org/r/20260721152424.521567757@linuxfoundation.org
Tested-by: Brett A C Sheffield &lt;bacs@librecast.net&gt;
Tested-by: Peter Schneider &lt;pschneider1968@googlemail.com&gt;
Tested-by: Ron Economos &lt;re@w6rz.net&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Pavel Machek (CIP) &lt;pavel@nabladev.com&gt;
Link: https://lore.kernel.org/r/20260722143218.909123637@linuxfoundation.org
Tested-by: Brett A C Sheffield &lt;bacs@librecast.net&gt;
Tested-by: Pavel Machek (CIP) &lt;pavel@nabladev.com&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Francesco Dolcini &lt;francesco.dolcini@toradex.com&gt;
Tested-by: Peter Schneider &lt;pschneider1968@googlemail.com&gt;
Tested-by: Shung-Hsi Yu &lt;shung-hsi.yu@suse.com&gt;
Tested-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
Tested-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>perf/x86/amd/core: Always use the NMI latency mitigation</title>
<updated>2026-07-24T13:55:19+00:00</updated>
<author>
<name>Sandipan Das</name>
<email>sandipan.das@amd.com</email>
</author>
<published>2026-06-01T14:58:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=83de1cc01e77efb10cbc35025bdee4c78a961bc5'/>
<id>urn:sha1:83de1cc01e77efb10cbc35025bdee4c78a961bc5</id>
<content type='text'>
commit 73a4c02f94a98d94480c3e5c81450215a4da05ba upstream.

Commit df4d29732fda ("perf/x86/amd: Change/fix NMI latency mitigation
to use a timestamp") fixed handling of late-arriving NMIs but limited
the mitigation to processors having X86_FEATURE_PERFCTR_CORE. However,
it is unclear if processors without this feature are also affected.
When Mediated vPMU is enabled on affected hardware, it is also possible
to bypass the fix inside KVM guests if X86_FEATURE_PERFCTR_CORE is
removed from the guest CPUID (e.g. using "-cpu host,-perfctr-core" with
QEMU). Hence, use the mitigation at all times.

Fixes: df4d29732fda ("perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp")
Signed-off-by: Sandipan Das &lt;sandipan.das@amd.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Link: https://patch.msgid.link/29a3c970da289ab8f24282933bdb36545c0403e8.1780325517.git.sandipan.das@amd.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()</title>
<updated>2026-07-24T13:55:19+00:00</updated>
<author>
<name>HyeongJun An</name>
<email>sammiee5311@gmail.com</email>
</author>
<published>2026-06-23T23:38:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a224c84e5d3d35708c082c84ad12d81d90762195'/>
<id>urn:sha1:a224c84e5d3d35708c082c84ad12d81d90762195</id>
<content type='text'>
commit 435990e25bf1f4af3e6df12a6fbfd1f7ba4a97d4 upstream.

snd_seq_event_dup() copies an incoming event into a pool cell and, in
the UMP-enabled build, clears the trailing cell-&gt;ump.raw.extra word that
the memcpy() did not cover.  The guard deciding whether to clear it
compares the copied size against sizeof(cell-&gt;event):

	memcpy(&amp;cell-&gt;ump, event, size);
	if (size &lt; sizeof(cell-&gt;event))
		cell-&gt;ump.raw.extra = 0;

For a legacy (non-UMP) event, size == sizeof(struct snd_seq_event) ==
sizeof(cell-&gt;event), so the condition is false and the extra word keeps
stale data.  The cell pool is allocated with kvmalloc() (not zeroed) and
cells are reused via a free list, so that word holds uninitialised heap
or leftover event data.

When such a cell is delivered to a UMP client (client-&gt;midi_version &gt; 0)
that set SNDRV_SEQ_FILTER_NO_CONVERT -- so the legacy event reaches it
unconverted -- snd_seq_read() reads it out as the larger struct
snd_seq_ump_event and copies the stale word to user space, a 4-byte
kernel heap infoleak to an unprivileged /dev/snd/seq client.

Compare against sizeof(cell-&gt;ump) instead, so the trailing word is zeroed
for every event shorter than the UMP cell.

Fixes: 46397622a3fa ("ALSA: seq: Add UMP support")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: HyeongJun An &lt;sammiee5311@gmail.com&gt;
Link: https://patch.msgid.link/20260623233841.853326-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iio: imu: inv_icm42600: fix timestamp clock period by using lower value</title>
<updated>2026-07-24T13:55:19+00:00</updated>
<author>
<name>Jean-Baptiste Maneyrol</name>
<email>jean-baptiste.maneyrol@tdk.com</email>
</author>
<published>2026-06-23T14:22:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4d94fb171ac22fdcfeb3f9d6301a42a61122f6e1'/>
<id>urn:sha1:4d94fb171ac22fdcfeb3f9d6301a42a61122f6e1</id>
<content type='text'>
commit 8b0b864c11a2e2ada470f9d5010e1c2bf1eceef2 upstream.

Clock period value is used for computing periods of sampling. There is
no need for it to be higher than the maximum odr, otherwise we are
losing precision in the computation for nothing.

Switch clock period value to maximum odr period (8kHz).

Fixes: 0ecc363ccea7 ("iio: make invensense timestamp module generic")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol &lt;jean-baptiste.maneyrol@tdk.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: seq: Check UMP support for midi_version change</title>
<updated>2026-07-24T13:55:19+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2024-12-31T14:53:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29ef3cf8c735cac31f1a9e85aac9db8c9c565e00'/>
<id>urn:sha1:29ef3cf8c735cac31f1a9e85aac9db8c9c565e00</id>
<content type='text'>
commit 8765429279e7d3d68d39ace5f84af2815174bb1e upstream.

When the kernel is built without UMP support but a user-space app
requires the midi_version &gt; 0, the kernel should return an error.
Otherwise user-space assumes as if it were possible to deal,
eventually hitting serious errors later.

Fixes: 46397622a3fa ("ALSA: seq: Add UMP support")
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://patch.msgid.link/20241231145358.21946-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: seq: Skip event type filtering for UMP events</title>
<updated>2026-07-24T13:55:19+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2024-08-19T08:41:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=96531369e2868d4678488a3db2fa8cbf64c17e36'/>
<id>urn:sha1:96531369e2868d4678488a3db2fa8cbf64c17e36</id>
<content type='text'>
commit 32108c22ac619c32dd6db594319e259b63bfb387 upstream.

UMP events don't use the event type field, hence it's invalid to apply
the filter, which may drop the events unexpectedly.
Skip the event filtering for UMP events, instead.

Fixes: 46397622a3fa ("ALSA: seq: Add UMP support")
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://patch.msgid.link/20240819084156.10286-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX</title>
<updated>2026-07-24T13:55:19+00:00</updated>
<author>
<name>Pavel Skripkin</name>
<email>paskripkin@gmail.com</email>
</author>
<published>2024-06-20T19:27:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2ae8d7742a09c275872e670c53337b3dcedaa11c'/>
<id>urn:sha1:2ae8d7742a09c275872e670c53337b3dcedaa11c</id>
<content type='text'>
commit 1cc18c2ab2e8c54c355ea7c0423a636e415a0c23 upstream.

Syzbot hit warning in hci_conn_del() caused by freeing handle that was
not allocated using ida allocator.

This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by
hci_le_big_sync_established_evt(), which makes code think it's unset
connection.

Add same check for handle upper bound as in hci_conn_set_handle() to
prevent warning.

Link: https://syzkaller.appspot.com/bug?extid=b2545b087a01a7319474
Reported-by: syzbot+b2545b087a01a7319474@syzkaller.appspotmail.com
Fixes: 181a42edddf5 ("Bluetooth: Make handle of hci_conn be unique")
Signed-off-by: Pavel Skripkin &lt;paskripkin@gmail.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Ignore too large handle values in BIG</title>
<updated>2026-07-24T13:55:19+00:00</updated>
<author>
<name>Edward Adam Davis</name>
<email>eadavis@qq.com</email>
</author>
<published>2024-06-17T11:09:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a06a8cc80fa203fde828a8429583f7e4fe27eca4'/>
<id>urn:sha1:a06a8cc80fa203fde828a8429583f7e4fe27eca4</id>
<content type='text'>
commit 015d79c96d62cd8a4a359fcf5be40d58088c936b upstream.

hci_le_big_sync_established_evt is necessary to filter out cases where the
handle value is belonging to ida id range, otherwise ida will be erroneously
released in hci_conn_cleanup.

Fixes: 181a42edddf5 ("Bluetooth: Make handle of hci_conn be unique")
Reported-by: syzbot+b2545b087a01a7319474@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b2545b087a01a7319474
Signed-off-by: Edward Adam Davis &lt;eadavis@qq.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iio: invensense: fix odr switching to same value</title>
<updated>2026-07-24T13:55:19+00:00</updated>
<author>
<name>Jean-Baptiste Maneyrol</name>
<email>jean-baptiste.maneyrol@tdk.com</email>
</author>
<published>2024-05-24T12:48:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=743b6c64884f15baa3c101f07698160a9649ac34'/>
<id>urn:sha1:743b6c64884f15baa3c101f07698160a9649ac34</id>
<content type='text'>
commit 95444b9eeb8c5c0330563931d70c61ca3b101548 upstream.

ODR switching happens in 2 steps, update to store the new value and then
apply when the ODR change flag is received in the data. When switching to
the same ODR value, the ODR change flag is never happening, and frequency
switching is blocked waiting for the never coming apply.

Fix the issue by preventing update to happen when switching to same ODR
value.

Fixes: 0ecc363ccea7 ("iio: make invensense timestamp module generic")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol &lt;jean-baptiste.maneyrol@tdk.com&gt;
Link: https://lore.kernel.org/r/20240524124851.567485-1-inv.git-commit@tdk.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iio: imu: inv_mpu6050: fix frequency setting when chip is off</title>
<updated>2026-07-24T13:55:18+00:00</updated>
<author>
<name>Jean-Baptiste Maneyrol</name>
<email>jean-baptiste.maneyrol@tdk.com</email>
</author>
<published>2024-02-19T15:47:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=15de69c3805ce503a6a23037cd627f28340e8b13'/>
<id>urn:sha1:15de69c3805ce503a6a23037cd627f28340e8b13</id>
<content type='text'>
commit daec424cc57b33a28f8621eb7ac85f8bd327bd6b upstream.

Track correctly FIFO state and apply ODR change before starting
the chip. Without the fix, you cannot change ODR more than 1 time
when data buffering is off. This restriction on a single pending ODR
change should only apply when the FIFO is on.

Fixes: 111e1abd0045 ("iio: imu: inv_mpu6050: use the common inv_sensors timestamp module")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol &lt;jean-baptiste.maneyrol@tdk.com&gt;
Link: https://lore.kernel.org/r/20240219154741.90601-1-inv.git-commit@tdk.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
