<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v7.0.11</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0.11</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-01T15:54:54+00:00</updated>
<entry>
<title>drm/msm: Restore second parameter name in purge() and evict()</title>
<updated>2026-06-01T15:54:54+00:00</updated>
<author>
<name>Nathan Chancellor</name>
<email>nathan@kernel.org</email>
</author>
<published>2026-05-18T22:17:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=277b03a518bd83684a0513f7ca96e5ee2f197536'/>
<id>urn:sha1:277b03a518bd83684a0513f7ca96e5ee2f197536</id>
<content type='text'>
[ Upstream commit 53676e4d44d6b38c8a0d9bff331f170ae2e41bbe ]

After commit 3392291fc509 ("drm/msm: Fix shrinker deadlock"), all
supported versions of clang warn (or error with CONFIG_WERROR=y):

  drivers/gpu/drm/msm/msm_gem_shrinker.c:105:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions]
    105 | purge(struct drm_gem_object *obj, struct ww_acquire_ctx *)
        |                                                          ^
  drivers/gpu/drm/msm/msm_gem_shrinker.c:117:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions]
    117 | evict(struct drm_gem_object *obj, struct ww_acquire_ctx *)
        |                                                          ^
  2 errors generated.

With older but supported versions of GCC, this is an unconditional hard error:

  drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'purge':
  drivers/gpu/drm/msm/msm_gem_shrinker.c:105:35: error: parameter name omitted
   purge(struct drm_gem_object *obj, struct ww_acquire_ctx *)
                                     ^~~~~~~~~~~~~~~~~~~~~~~
  drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'evict':
  drivers/gpu/drm/msm/msm_gem_shrinker.c:117:35: error: parameter name omitted
   evict(struct drm_gem_object *obj, struct ww_acquire_ctx *)
                                     ^~~~~~~~~~~~~~~~~~~~~~~

Restore the parameter name to clear up the warnings, renaming it
"unused" to make it clear it is only needed to satisfy the prototype of
drm_gem_lru_scan().

Cc: stable@vger.kernel.org
Fixes: 3392291fc509 ("drm/msm: Fix shrinker deadlock")
Signed-off-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: uniwill-laptop: Do not enable the charging limit even when forced</title>
<updated>2026-06-01T15:54:54+00:00</updated>
<author>
<name>Armin Wolf</name>
<email>W_Armin@gmx.de</email>
</author>
<published>2026-05-12T23:21:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c832a00c9b929b9ad26772833d425f520b2e09cd'/>
<id>urn:sha1:c832a00c9b929b9ad26772833d425f520b2e09cd</id>
<content type='text'>
[ Upstream commit 26cbe119f99c86dcb4a0136d2bc73c0c716d80e4 ]

It seems that on some older models (~2020) the battery charging limit
can permanently damage the battery. Prevent users from enabling this
feature thru the "force" module parameter to avoid causing permanent
hardware damage on such devices.

Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver")
Link: https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/
Reviewed-by: Werner Sembach &lt;wse@tuxedocomputers.com&gt;
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Armin Wolf &lt;W_Armin@gmx.de&gt;
Link: https://patch.msgid.link/20260512232145.329260-5-W_Armin@gmx.de
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: enetc: fix missing error code when pf-&gt;vf_state allocation fails</title>
<updated>2026-06-01T15:54:54+00:00</updated>
<author>
<name>Wei Fang</name>
<email>wei.fang@nxp.com</email>
</author>
<published>2026-05-20T06:44:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=efd739bf8e317790cf0b216ddadcd3659fe8f102'/>
<id>urn:sha1:efd739bf8e317790cf0b216ddadcd3659fe8f102</id>
<content type='text'>
[ Upstream commit 5027266dea471e140f93dd534845c9c4f43219a3 ]

In enetc_pf_probe(), when the memory allocation for pf-&gt;vf_state fails,
the code jumps to the error handling label but the variable 'err' is not
assigned an appropriate error code beforehand. This causes the function
to return 0 (success) on an allocation failure path, misleading the
caller into thinking the probe succeeded. So set err to -ENOMEM before
jumping to the error handling label when the allocation for pf-&gt;vf_state
returns NULL.

Fixes: e15c5506dd39 ("net: enetc: allocate vf_state during PF probes")
Signed-off-by: Wei Fang &lt;wei.fang@nxp.com&gt;
Reviewed-by: Harshitha Ramamurthy &lt;hramamurthy@google.com&gt;
Link: https://patch.msgid.link/20260520064421.91569-3-wei.fang@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pds_core: ensure null-termination for firmware version strings</title>
<updated>2026-06-01T15:54:54+00:00</updated>
<author>
<name>Nikhil P. Rao</name>
<email>nikhil.rao@amd.com</email>
</author>
<published>2026-05-20T20:58:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b4f4c8120dd12039ec50fb4280ba55358d955c6d'/>
<id>urn:sha1:b4f4c8120dd12039ec50fb4280ba55358d955c6d</id>
<content type='text'>
[ Upstream commit 3d4432d34c1992701289cbe12df9fd024f315998 ]

The driver passes fw_version directly to devlink_info_version_stored_put()
without ensuring null-termination. While current firmware null-terminates
these strings, the driver should not rely on this behavior. Add explicit
null-termination to prevent potential issues if firmware behavior changes.

Fixes: 45d76f492938 ("pds_core: set up device and adminq")
Signed-off-by: Nikhil P. Rao &lt;nikhil.rao@amd.com&gt;
Link: https://patch.msgid.link/20260520205842.1486718-1-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: airoha: Disable GDM2 forwarding before configuring GDM2 loopback</title>
<updated>2026-06-01T15:54:54+00:00</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo@kernel.org</email>
</author>
<published>2026-05-20T13:12:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a4fd129c0148ba32ca89a024772ddc935bd0c3a1'/>
<id>urn:sha1:a4fd129c0148ba32ca89a024772ddc935bd0c3a1</id>
<content type='text'>
[ Upstream commit 985d4a55e64e43bd86eeb896b81ceba453301989 ]

Hw design requires to disable GDM2 forwarding before configuring GDM2
loopback in airoha_set_gdm2_loopback routine.

Fixes: 9cd451d414f6e ("net: airoha: Add loopback support for GDM2")
Tested-by: Madhur Agrawal &lt;madhur.agrawal@airoha.com&gt;
Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Link: https://patch.msgid.link/20260520-airoha-disable-gdm2-fwd-v1-1-1eeea5dffc2f@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDR</title>
<updated>2026-06-01T15:54:54+00:00</updated>
<author>
<name>Weiming Shi</name>
<email>bestswngs@gmail.com</email>
</author>
<published>2026-05-20T07:57:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=05305e832be7b9d65b2b72caacf7d850b3942b2a'/>
<id>urn:sha1:05305e832be7b9d65b2b72caacf7d850b3942b2a</id>
<content type='text'>
[ Upstream commit bddc09212c24934643bd44fc794748d2bbb3b6cd ]

In the SIOCGIFHWADDR path, tap_ioctl() copies 16 bytes of an
uninitialised on-stack struct sockaddr_storage to userspace via
ifr_hwaddr, but netif_get_mac_address() only writes sa_family and
dev-&gt;addr_len (6 for Ethernet) bytes, leaving sa_data[6..13] uninitialised.

Those 8 trailing bytes leak kernel stack contents; SIOCGIFHWADDR on a
macvtap chardev returns kernel .text and direct-map pointers, defeating
KASLR.

Initialise ss at declaration.

Fixes: 3b23a32a6321 ("net: fix dev_ifsioc_locked() race condition")
Reported-by: Xiang Mei &lt;xmei5@asu.edu&gt;
Signed-off-by: Weiming Shi &lt;bestswngs@gmail.com&gt;
Reviewed-by: Willem de Bruijn &lt;willemb@google.com&gt;
Link: https://patch.msgid.link/20260520075736.3415676-3-bestswngs@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: mana: validate rx_req_idx to prevent out-of-bounds array access</title>
<updated>2026-06-01T15:54:53+00:00</updated>
<author>
<name>Aditya Garg</name>
<email>gargaditya@linux.microsoft.com</email>
</author>
<published>2026-05-20T05:15:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=355e9f2b2a7887ca38100127989af3e422ba71d0'/>
<id>urn:sha1:355e9f2b2a7887ca38100127989af3e422ba71d0</id>
<content type='text'>
[ Upstream commit b809d0409991b75a6cff846a5ac27c3062953f84 ]

In mana_hwc_rx_event_handler(), rx_req_idx is derived from
sge-&gt;address in DMA-coherent memory. In Confidential VMs
(SEV-SNP/TDX), this memory is shared unencrypted and HW can modify
WQE contents at any time. No bounds check exists on rx_req_idx,
which can lead to an out-of-bounds access into reqs[].

Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before
using it to index the reqs[] array.

Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
Signed-off-by: Aditya Garg &lt;gargaditya@linux.microsoft.com&gt;
Reviewed-by: Haiyang Zhang &lt;haiyangz@microsoft.com&gt;
Link: https://patch.msgid.link/20260520051553.857120-1-gargaditya@linux.microsoft.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>octeontx2-af: npc: Fix allmulticast skip logic for LBK and SDP VFs</title>
<updated>2026-06-01T15:54:53+00:00</updated>
<author>
<name>Ratheesh Kannoth</name>
<email>rkannoth@marvell.com</email>
</author>
<published>2026-05-20T04:30:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b496926b28f4231267a2bc506c520d5c3323b9ed'/>
<id>urn:sha1:b496926b28f4231267a2bc506c520d5c3323b9ed</id>
<content type='text'>
[ Upstream commit 9eddc819f00b5b74bb4ac91396f80bd35f5f3561 ]

When installing the allmulticast NPC rule, rvu_npc_install_allmulti_entry()
should skip LBK and SDP VFs (only CGX PF/VF may add the entry).  The
code combined is_lbk_vf() and is_sdp_vf() with logical AND, which is
never true for a single pcifunc, so the intended early return never ran.

Use logical OR instead.

Cc: Geetha sowjanya &lt;gakula@marvell.com&gt;
Fixes: ae703539f49d2 ("octeontx2-af: Cleanup loopback device checks")
Signed-off-by: Ratheesh Kannoth &lt;rkannoth@marvell.com&gt;
Link: https://patch.msgid.link/20260520043036.1523798-1-rkannoth@marvell.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-pci: fix dma mapping leak on data setup error</title>
<updated>2026-06-01T15:54:53+00:00</updated>
<author>
<name>Keith Busch</name>
<email>kbusch@kernel.org</email>
</author>
<published>2026-05-19T20:01:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e50db059ec8e63bc50b1cc039e2502cb5ea75a70'/>
<id>urn:sha1:e50db059ec8e63bc50b1cc039e2502cb5ea75a70</id>
<content type='text'>
[ Upstream commit 1bf86336e4b6cf40873fda47a7fe191446864937 ]

We're leaking the initial DMA mapping during iteration if we fail to
allocate the tracking descriptor for both PRP and SGL. Unmap the
iterator directly; we can't use the existing unmap helper because it
depends on the tracking descriptor being successfully allocated, so a
new one for an in-use iterator is provided.

The mappings were also leaking when the driver detects an invalid
bio_vec when mapping PRPs, so fix that too.

Fixes: b8b7570a7ec87 ("nvme-pci: fix dma unmapping when using PRPs and not using the IOVA mapping")
Fixes: 7ce3c1dd78fca ("nvme-pci: convert the data mapping to blk_rq_dma_map")
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-pci: fix dma_vecs leak on p2p memory</title>
<updated>2026-06-01T15:54:53+00:00</updated>
<author>
<name>Keith Busch</name>
<email>kbusch@kernel.org</email>
</author>
<published>2026-05-20T01:03:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=24ea0de233d9ebb5ebd6f6018eaf2084af25e3dd'/>
<id>urn:sha1:24ea0de233d9ebb5ebd6f6018eaf2084af25e3dd</id>
<content type='text'>
[ Upstream commit 85686c72966c5ee637893f124ddb31a1cace7bee ]

We don't unmap P2P memory, so we don't need to track it. The dma_vec
allocation was getting leaked on the completion.

Fixes: b8b7570a7ec87 ("nvme-pci: fix dma unmapping when using PRPs and not using the IOVA mapping")
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
