6.1.183-rc1 review
Greg Kroah-Hartman
maintainerPATCH 126/609 net: dpaa2-eth: assign priv->mac after dpaa2_mac_connect() call
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit 02d61948e8daf3844d0af41ba5d563ef03cc7c4f ]
There are 2 requirements for correct code:
- Any time the driver accesses the priv->mac pointer at runtime, it either holds NULL to indicate a DPNI-DPNI connection (or unconnected DPNI), or a struct dpaa2_mac whose phylink instance was fully initialized (created and connected to the PHY). No changes are made to priv->mac while it is being used. Currently, rtnl_lock() watches over the call to dpaa2_eth_connect_mac(), so it serves the purpose of serializing this with all readers of priv->mac.
- dpaa2_mac_connect() should run unlocked, because inside it are 2 phylink calls with incompatible locking requirements: phylink_create() requires that the rtnl_mutex isn't held, and phylink_fwnode_phy_connect() requires that the rtnl_mutex is held. The only way to solve those contradictory requirements is to let dpaa2_mac_connect() take rtnl_lock() when it needs to.
To solve both requirements, we need to identify the writer side of the priv->mac pointer, which can be wrapped in a mutex private to the driver in a future patch. The dpaa2_mac_connect() cannot be part of the writer side critical section, because of an AB/BA deadlock with rtnl_lock().
So the strategy needs to be that where we prepare the DPMAC by calling dpaa2_mac_connect(), and only make priv->mac point to it once it's fully prepared. This ensures that the writer side critical section has the absolute minimum surface it can.
The reverse strategy is adopted in the dpaa2_eth_disconnect_mac() code path. This makes sure that priv->mac is NULL when we start tearing down the DPMAC that we disconnected from, and concurrent code will simply not see it.
No locking changes in this patch (concurrent code is still blocked by the rtnl_mutex).
Stable-dep-of: b4b201cc93ff ("dpaa2-eth: put MAC endpoint device on disconnect")
--- .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 21 +++++++++++-------- 1 file changed, 12 insertions(+), 9 deletions(-)
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c +12 -9
@@ -4466,9 +4466,8 @@ static int dpaa2_eth_connect_mac(struct dpaa2_eth_priv *priv) err =dpaa2_mac_open (mac);if (err) goto err_free_mac; - priv->mac = mac; -if (dpaa2_eth_is_type_phy (priv)) { +if (dpaa2_mac_is_type_phy (mac)) { err =dpaa2_mac_connect (mac);if (err && err != -EPROBE_DEFER ) netdev_err(priv->net_dev, "Error connecting to the MAC endpoint: %pe",
@@ -4477,11 +4476,12 @@ static int dpaa2_eth_connect_mac(struct dpaa2_eth_priv *priv) goto err_close_mac; } + priv->mac = mac; +return 0 ; err_close_mac:dpaa2_mac_close (mac); - priv->mac =NULL ; err_free_mac:kfree (mac); out_put_device:
@@ -4491,15 +4491,18 @@ static int dpaa2_eth_connect_mac(struct dpaa2_eth_priv *priv)static void dpaa2_eth_disconnect_mac (struct dpaa2_eth_priv *priv) { -if (dpaa2_eth_is_type_phy (priv)) -dpaa2_mac_disconnect (priv->mac); +struct dpaa2_mac *mac = priv->mac; -if (!dpaa2_eth_has_mac (priv)) + priv->mac =NULL ; + +if (!mac)return ; -dpaa2_mac_close (priv->mac); -kfree (priv->mac); - priv->mac =NULL ; +if (dpaa2_mac_is_type_phy (mac)) +dpaa2_mac_disconnect (mac); + +dpaa2_mac_close (mac); +kfree (mac); }static irqreturn_t dpni_irq0_handler_thread (int irq_num,void *arg)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 127/609 dpaa2-eth: put MAC endpoint device on disconnect
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guangshuo Li <[email protected]>
[ Upstream commit b4b201cc93ff70150853aba03e14d314d1980ca0 ]
fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object.
However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected.
Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.
--- drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c +1 -0
@@ -4502,6 +4502,7 @@ static void dpaa2_eth_disconnect_mac(struct dpaa2_eth_priv *priv)dpaa2_mac_disconnect (mac);dpaa2_mac_close (mac); +put_device (&mac->mc_dev->dev);kfree (mac); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 128/609 nfp: Check resource mutex allocation
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ruoyu Wang <[email protected]>
[ Upstream commit a61b4db34a753bdf5c9e77a7f3d3dddd41dcfacc ]
nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock().
However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource.
nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle.
This issue was found by a static analysis checker and confirmed by manual source review.
--- drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c +3 -0
@@ -96,6 +96,9 @@ static int nfp_cpp_resource_find(struct nfp_cpp *cpp, struct nfp_resource *res) res->mutex =nfp_cpp_mutex_alloc (cpp,NFP_RESOURCE_TBL_TARGET , addr, key); +if (!res->mutex) +return -ENOMEM ; + res->cpp_id =NFP_CPP_ID (entry.region.cpp_target, entry.region.cpp_action, entry.region.cpp_token);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 129/609 wan: wanxl: Only reset hardware after BAR mapping
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ruoyu Wang <[email protected]>
[ Upstream commit 91957b89da995607cb654b1f9a3c126ddbaee10f ]
wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask.
wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer.
Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated.
This issue was found by a static analysis checker and confirmed by manual source review.
--- drivers/net/wan/wanxl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wan/wanxl.c +2 -1
@@ -514,7 +514,8 @@ static void wanxl_pci_remove_one(struct pci_dev *pdev)if (card->irq)free_irq (card->irq, card); -wanxl_reset (card); +if (card->plx) +wanxl_reset (card);for (i =0 ; i <RX_QUEUE_LENGTH ; i++)if (card->rx_skbs[i]) {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 130/609 wifi: mwifiex: bound uAP association event IEs to the event buffer
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: HE WEI (ギカク) <[email protected]>
[ Upstream commit f0858bfc7d3cab411a447b88e3ef970e575032c9 ]
mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event:
sinfo->assoc_req_ies = &event->data[len]; len = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; sinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len;
event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter.
On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification.
A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode.
Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 ("wifi: mwifiex: Fix OOB and integer underflow when rx packets").
--- .../net/wireless/marvell/mwifiex/uap_event.c | 24 +++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-)
drivers/net/wireless/marvell/mwifiex/uap_event.c +22 -2
@@ -123,11 +123,31 @@ int mwifiex_process_uap_event(struct mwifiex_private *priv) len =ETH_ALEN ;if (len !=-1 ) { +u16 evt_len =le16_to_cpu (event->len); + sinfo->assoc_req_ies = &event->data[len]; len = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; - sinfo->assoc_req_ies_len = -le16_to_cpu (event->len) - (u16 )len; + +/* +* event->len is reported by the device firmware +* and is not otherwise validated. Reject a +* length that underflows the header, or that +* would place the association request IEs +* outside the fixed-size event_body[] buffer the +* event was copied into; otherwise the IE walk +* in mwifiex_set_sta_ht_cap() reads past +* event_body and out of the adapter slab object. +*/ +if (evt_len < len || + (u8 *)&event->frame_control + evt_len > + adapter->event_body +MAX_EVENT_SIZE ) { +mwifiex_dbg (adapter,ERROR , +"invalid STA assoc event length\n" ); +kfree (sinfo); +return -1 ; + } + sinfo->assoc_req_ies_len = evt_len - (u16 )len; } } cfg80211_new_sta(priv->netdev, event->sta_addr, sinfo,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 131/609 iommu/amd: Bound the early ACPI HID map
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pengpeng Hou <[email protected]>
[ Upstream commit fb80117fddb5b477218dc99bb53911b72c3847f8 ]
The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size.
Check the capacity at the common found label before parsing the HID and UID or writing the entry.
--- drivers/iommu/amd/init.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/iommu/amd/init.c +6 -0
@@ -3603,6 +3603,12 @@ static int __init parse_ivrs_acpihid(char *str)return 1 ; found: +if (early_acpihid_map_size ==EARLY_MAP_SIZE ) { +pr_err ("Early ACPI HID map overflow - ignoring ivrs_acpihid%s\n" , + str); +return 1 ; + } + p = acpiid; hid =strsep (&p,":" ); uid = p;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 132/609 iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li RongQing <[email protected]>
[ Upstream commit 754f8efe45f87e3a9c6871b645b2f9d46d1b407b ]
dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type].
When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory.
Fix by using sizeof(*lstat) to clear only the target entry.
--- drivers/iommu/intel/perf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iommu/intel/perf.c +1 -1
@@ -63,7 +63,7 @@ void dmar_latency_disable(struct intel_iommu *iommu, enum latency_type type)return ;spin_lock_irqsave (&latency_lock, flags); -memset (&lstat[type],0 ,sizeof (*lstat) *DMAR_LATENCY_NUM ); +memset (&lstat[type],0 ,sizeof (*lstat));spin_unlock_irqrestore (&latency_lock, flags); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 133/609 wifi: mac80211: recalculate TIM when a station enters power save
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Pope <[email protected]>
[ Upstream commit a007a384c9eb17610f53a53e2f59944c31f1565a ]
When an AP buffers frames for a station on its per-station TXQs and the station subsequently enters power save, sta_ps_start() records the buffered TIDs in txq_buffered_tids but does not update the TIM. The station's TIM bit is only ever set when a further frame is buffered while the station is already asleep (ieee80211_tx_h_unicast_ps_buf() -> sta_info_recalc_tim()).
If no further downlink frame arrives for that station the beacon TIM never advertises the buffered traffic. A station relying on the TIM then remains in doze indefinitely on top of a non-empty queue. Its TXQs were removed from the scheduler's active list at PS entry, nothing pages it, and the flow deadlocks until an unrelated event wakes the station.
Recalculate the TIM at the end of sta_ps_start(), so traffic already buffered at PS entry is advertised immediately. sta_info_recalc_tim() already consults txq_buffered_tids, which is updated above, and is safe in this context (it is already called from equivalent paths such as the tx handlers and ieee80211_handle_filtered_frame()).
--- net/mac80211/rx.c | 2 ++ 1 file changed, 2 insertions(+)
net/mac80211/rx.c +2 -0
@@ -1590,6 +1590,8 @@ static void sta_ps_start(struct sta_info *sta)else clear_bit (tid, &sta->txq_buffered_tids); } + +sta_info_recalc_tim (sta); }static void sta_ps_end (struct sta_info *sta)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 134/609 amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prashanth Kumar KR <[email protected]>
[ Upstream commit 4bf22afe53a1de4b44b04cf677fd5199089cbdff ]
MAC_AUTO_SW (VR_MII_DIG_CTRL1 bit 9) enables automatic XPCS speed mode switching after CL37 auto-negotiation and is only meaningful in SGMII MAC mode. The original code unconditionally set this bit on every call to xgbe_an37_set(), including when called from xgbe_an37_disable() with enable=false. This left MAC_AUTO_SW=1 after AN was disabled, causing the XPCS to autonomously switch speed from stale AN state during subsequent mode changes, breaking SGMII speed negotiation on 1G copper SFP modules.
Patrick: This was breaking negotiation for all 1G SFP modules, not just copper modules.
--- drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c +8 -3
@@ -364,9 +364,14 @@ static void xgbe_an37_set(struct xgbe_prv_data *pdata, bool enable,XMDIO_WRITE (pdata,MDIO_MMD_VEND2 ,MDIO_CTRL1 , reg); - reg =XMDIO_READ (pdata,MDIO_MMD_VEND2 ,MDIO_PCS_DIG_CTRL ); - reg |=XGBE_VEND2_MAC_AUTO_SW ; -XMDIO_WRITE (pdata,MDIO_MMD_VEND2 ,MDIO_PCS_DIG_CTRL , reg); +if (pdata->an_mode ==XGBE_AN_MODE_CL37_SGMII ) { + reg =XMDIO_READ (pdata,MDIO_MMD_VEND2 ,MDIO_PCS_DIG_CTRL ); +if (enable) + reg |=XGBE_VEND2_MAC_AUTO_SW ; +else + reg &= ~XGBE_VEND2_MAC_AUTO_SW ; +XMDIO_WRITE (pdata,MDIO_MMD_VEND2 ,MDIO_PCS_DIG_CTRL , reg); + } }static void xgbe_an37_restart (struct xgbe_prv_data *pdata)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 135/609 sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: HanQuan <[email protected]>
[ Upstream commit ff04b26794a16a8a879eb4fd2c02c2d6b03850e9 ]
sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes.
Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.
--- net/sctp/auth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/sctp/auth.c +1 -1
@@ -766,7 +766,7 @@ int sctp_auth_ep_add_chunkid(struct sctp_endpoint *ep, __u8 chunk_id)/* Check if we can add this chunk to the array */ param_len =ntohs (p->param_hdr.length); nchunks = param_len -sizeof (struct sctp_paramhdr ); -if (nchunks ==SCTP_NUM_CHUNK_TYPES ) +if (nchunks ==SCTP_AUTH_MAX_CHUNKS )return -EINVAL ; p->chunks[nchunks] = chunk_id;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 136/609 sctp: validate stream count in sctp_process_strreset_inreq()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cen Zhang (Microsoft) <[email protected]>
[ Upstream commit 18ae07691d43183d270de8be9dc8e027906015d9 ]
When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN.
The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG:
net/core/skbuff.c:207 skb_panic
net/core/skbuff.c:2625 skb_put
net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req
net/sctp/stream.c:655 sctp_process_strreset_inreq
The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer.
Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.
--- net/sctp/stream.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/sctp/stream.c +5 -1
@@ -308,7 +308,8 @@ int sctp_send_reset_streams(struct sctp_association *asoc, goto out; param_len += str_nums *sizeof (__u16) + -sizeof (struct sctp_strreset_inreq ); + (out ?sizeof (struct sctp_strreset_inreq ) + :sizeof (struct sctp_strreset_outreq )); } if (param_len > SCTP_MAX_CHUNK_LEN -
@@ -639,6 +640,9 @@ struct sctp_chunk *sctp_process_strreset_inreq( nums = (ntohs (param.p->length) -sizeof (*inreq)) /sizeof (__u16); str_p = inreq->list_of_streams; +if (nums *sizeof (__u16) +sizeof (struct sctp_strreset_outreq ) > +SCTP_MAX_CHUNK_LEN -sizeof (struct sctp_reconf_chunk )) + goto out;for (i =0 ; i < nums; i++) {if (ntohs (str_p[i]) >= stream->outcnt) { result =SCTP_STRRESET_ERR_WRONG_SSN ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 137/609 selftest: af_unix: Add Kconfig file.
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 11b006d6896c0471ad29c6f1fb1af606e7ba278f ]
diag_uid selftest failed on NIPA where the received nlmsg_type is NLMSG_ERROR [0] because CONFIG_UNIX_DIAG is not set [1] by default and sock_diag_lock_handler() failed to load the module.
# # Starting 2 tests from 2 test cases.
# # RUN diag_uid.uid.1 ...
# # diag_uid.c:159:1:Expected nlh->nlmsg_type (2) == SOCK_DIAG_BY_FAMILY (20) # # 1: Test terminated by assertion
# # FAIL diag_uid.uid.1
# not ok 1 diag_uid.uid.1
Let's add all AF_UNIX Kconfig to the config file under af_unix dir so that NIPA consumes it.
Stable-dep-of: f8b1abed7361 ("selftests: af_unix: add USER_NS config")
--- tools/testing/selftests/net/af_unix/config | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 tools/testing/selftests/net/af_unix/config
tools/testing/selftests/net/af_unix/config new file +3 -0
@@ -0,0 +1,3 @@ +CONFIG_UNIX=y +CONFIG_AF_UNIX_OOB=y +CONFIG_UNIX_DIAG=m
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 138/609 selftests: af_unix: add USER_NS config
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
[ Upstream commit f8b1abed736111f914b2c567d9a3db1f71e788e8 ]
This is required to use unshare(CLONE_NEWUSER).
This has not been seen on NIPA before, because the 'af_unix' tests are executed with the 'net' ones, merging their config files. USER_NS is present in tools/testing/selftests/net/config.
This issue is visible when only the af_unix config is used on top of the default one. This is the recommended way to execute selftest targets.
--- tools/testing/selftests/net/af_unix/config | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/net/af_unix/config +1 -0
@@ -1,3 +1,4 @@ CONFIG_UNIX=y CONFIG_AF_UNIX_OOB=y CONFIG_UNIX_DIAG=m +CONFIG_USER_NS=y
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 139/609 selftests: openvswitch: add config file
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
[ Upstream commit 441a820ccef9af80a9ac5a4c85b9c396e595967c ]
The kselftests doc mentions that a config file should be present "if a test needs specific kernel config options enabled". This selftest requires some kernel config, but no config file was provided.
We could say that a sub-target could use the parent's config file, but the kselftests doc doesn't mention anything about that. Plus the net/openvswitch target is the only net target without a config file.
Here is a new config file, which is a trimmed version of the net one, with hopefully the minimal required kconfig on top of 'make defconfig'.
The Fixes tag points to the introduction of the net/openvswitch target, just to help validating this target on stable kernels.
--- tools/testing/selftests/net/openvswitch/config | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 tools/testing/selftests/net/openvswitch/config
tools/testing/selftests/net/openvswitch/config new file +16 -0
@@ -0,0 +1,16 @@ +CONFIG_GENEVE=m +CONFIG_INET_DIAG=y +CONFIG_IPV6=y +CONFIG_NETFILTER=y +CONFIG_NET_IPGRE=m +CONFIG_NET_IPGRE_DEMUX=m +CONFIG_NF_CONNTRACK=m +CONFIG_NF_CONNTRACK_OVS=y +CONFIG_OPENVSWITCH=m +CONFIG_OPENVSWITCH_GENEVE=m +CONFIG_OPENVSWITCH_GRE=m +CONFIG_OPENVSWITCH_VXLAN=m +CONFIG_PSAMPLE=m +CONFIG_VETH=y +CONFIG_VLAN_8021Q=y +CONFIG_VXLAN=m
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 140/609 gtp: check skb_pull_data() return in gtp1u_send_echo_resp()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiang Mei (Microsoft) <[email protected]>
[ Upstream commit cd170f051dba9ac146fabcd1b91726487c0cb9fa ]
gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic().
Fix it by dropping the packet when skb_pull_data() fails.
skbuff: skb_under_panic: ...
kernel BUG at net/core/skbuff.c:214!
Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt
--- drivers/net/gtp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/gtp.c +3 -2
@@ -489,8 +489,9 @@ static int gtp1u_send_echo_resp(struct gtp_dev *gtp, struct sk_buff *skb)return -1 ;/* pull GTP and UDP headers */ -skb_pull_data (skb, -sizeof (struct gtp1_header_long ) +sizeof (struct udphdr )); +if (!skb_pull_data (skb,sizeof (struct gtp1_header_long ) + +sizeof (struct udphdr ))) +return -1 ; gtp_pkt =skb_push (skb,sizeof (struct gtp1u_packet ));memset (gtp_pkt,0 ,sizeof (struct gtp1u_packet ));
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 141/609 nexthop: initialize extack in nh_res_bucket_migrate()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiang Mei (Microsoft) <[email protected]>
[ Upstream commit 6347c5314cee49f364aaf2e40ff15415a57a116e ]
nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited("%s\n", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory:
Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception
Zero-initialize extack so _msg is NULL on error paths that never set it.
--- net/ipv4/nexthop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/nexthop.c +1 -1
@@ -1504,8 +1504,8 @@ static bool nh_res_bucket_migrate(struct nh_res_table *res_table, bool notify_nl, bool force) {struct nh_res_bucket *bucket = &res_table->nh_buckets[bucket_index]; +struct netlink_ext_ack extack = {};struct nh_grp_entry *new_nhge; -struct netlink_ext_ack extack;int err; new_nhge = list_first_entry_or_null(&res_table->uw_nh_entries,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 142/609 tipc: fix infinite loop in __tipc_nl_compat_dumpit
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helen Koike <[email protected]>
[ Upstream commit 22f8aa35964e8f2ab026578f45befc9605fd1b28 ]
cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state.
Check dumpit's return value, propagate it and jump to err_out on error.
--- net/tipc/netlink_compat.c | 4 ++++ 1 file changed, 4 insertions(+)
net/tipc/netlink_compat.c +4 -0
@@ -226,6 +226,10 @@ static int __tipc_nl_compat_dumpit(struct tipc_nl_compat_cmd_dump *cmd,int rem; len = (*cmd->dumpit)(buf, &cb); +if (len <0 ) { + err = len; + goto err_out; + }nlmsg_for_each_msg (nlmsg,nlmsg_hdr (buf), len, rem) { err = nlmsg_parse_deprecated(nlmsg, GENL_HDRLEN,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 143/609 wifi: mt76: mt7915: guard HE capability lookups
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ruoyu Wang <[email protected]>
[ Upstream commit 8e9db062654a388d0fa587acbeeae68dd33eba41 ]
mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type.
Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.
--- .../net/wireless/mediatek/mt76/mt7915/mcu.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c +13 -5
@@ -518,6 +518,8 @@ mt7915_mcu_bss_he_tlv(struct sk_buff *skb, struct ieee80211_vif *vif,struct tlv *tlv; cap =mt76_connac_get_he_phy_cap (phy->mt76, vif); +if (!cap) +return ; tlv =mt76_connac_mcu_add_tlv (skb,BSS_INFO_HE_BASIC ,sizeof (*he));
@@ -1098,13 +1100,12 @@ mt7915_mcu_sta_bfer_vht(struct ieee80211_sta *sta, struct mt7915_phy *phy, }static void -mt7915_mcu_sta_bfer_he (struct ieee80211_sta *sta,struct ieee80211_vif *vif, -struct mt7915_phy *phy,struct sta_rec_bf *bf) +mt7915_mcu_sta_bfer_he (struct ieee80211_sta *sta, +const struct ieee80211_sta_he_cap *vc, +struct sta_rec_bf *bf) {struct ieee80211_sta_he_cap *pc = &sta->deflink.he_cap;struct ieee80211_he_cap_elem *pe = &pc->he_cap_elem; -const struct ieee80211_sta_he_cap *vc = -mt76_connac_get_he_phy_cap (phy->mt76, vif);const struct ieee80211_he_cap_elem *ve = &vc->he_cap_elem;u16 mcs_map =le16_to_cpu (pc->he_mcs_nss_supp.rx_mcs_80);u8 nss_mcs =mt7915_mcu_get_sta_nss (mcs_map);
@@ -1163,6 +1164,7 @@ mt7915_mcu_sta_bfer_tlv(struct mt7915_dev *dev, struct sk_buff *skb, {struct mt7915_vif *mvif = (struct mt7915_vif *)vif->drv_priv;struct mt7915_phy *phy = mvif->phy; +const struct ieee80211_sta_he_cap *vc =NULL ;int tx_ant =hweight8 (phy->mt76->chainmask) -1 ;struct sta_rec_bf *bf;struct tlv *tlv;
@@ -1181,6 +1183,12 @@ mt7915_mcu_sta_bfer_tlv(struct mt7915_dev *dev, struct sk_buff *skb,if (!ebf && !dev->ibf)return ; +if (sta->deflink.he_cap.has_he && ebf) { + vc =mt76_connac_get_he_phy_cap (phy->mt76, vif); +if (!vc) +return ; + } + tlv =mt76_connac_mcu_add_tlv (skb,STA_REC_BF ,sizeof (*bf)); bf = (struct sta_rec_bf *)tlv;
@@ -1189,7 +1197,7 @@ mt7915_mcu_sta_bfer_tlv(struct mt7915_dev *dev, struct sk_buff *skb,* ht: iBF only, since mac80211 lacks of eBF support */ if (sta->deflink.he_cap.has_he && ebf) -mt7915_mcu_sta_bfer_he (sta, vif, phy, bf); +mt7915_mcu_sta_bfer_he (sta, vc, bf);else if (sta->deflink.vht_cap.vht_supported)mt7915_mcu_sta_bfer_vht (sta, phy, bf, ebf);else if (sta->deflink.ht_cap.ht_supported)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 144/609 wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lorenzo Bianconi <[email protected]>
[ Upstream commit 2c1fb2335f5e3afb34f91bc07ecb63517c328090 ]
mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.
--- drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c +2 -0
@@ -1298,6 +1298,8 @@ mt76_connac_mcu_uni_bss_he_tlv(struct mt76_phy *phy, struct ieee80211_vif *vif,struct bss_info_uni_he *he; cap =mt76_connac_get_he_phy_cap (phy, vif); +if (!cap) +return ; he = (struct bss_info_uni_he *)tlv; he->he_pe_duration = vif->bss_conf.htc_trig_based_pkt_ext;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 145/609 wifi: brcmfmac: fix 802.1X-SHA256 call trace warning
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shelley Yang <[email protected]>
[ Upstream commit 7cb34f6c4fe8a68af621d870abe63bfca2275dd6 ]
Based on wpa_auth as 1x_256 mode, need to set up "use_fwsup" with BRCMF_PROFILE_FWSUP_1X.
Or it will happen trace warning when call brcmf_cfg80211_set_pmk().
[ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204] <TASK> [ 4481.831205] nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233] genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237] genl_rcv_msg+0x104/0x240 [ 4481.831239] ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257] ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259] netlink_rcv_skb+0x4e/0x100 [ 4481.831261] genl_rcv+0x24/0x40 [ 4481.831262] netlink_unicast+0x236/0x380 [ 4481.831264] netlink_sendmsg+0x250/0x4b0 [ 4481.831266] sock_sendmsg+0x5c/0x70 [ 4481.831269] ____sys_sendmsg+0x236/0x2b0 [ 4481.831271] ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272] ___sys_sendmsg+0x86/0xd0 [ 4481.831274] ? avc_has_perm+0x8c/0x1a0 [ 4481.831276] ? preempt_count_add+0x6a/0xa0 [ 4481.831279] ? sock_has_perm+0x82/0xa0 [ 4481.831280] __sys_sendmsg+0x57/0xa0 [ 4481.831282] do_syscall_64+0x38/0x90 [ 4481.831284] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4
--- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +1 -1
@@ -1791,7 +1791,7 @@ brcmf_set_key_mgmt(struct net_device *ndev, struct cfg80211_connect_params *sme) sme->crypto.akm_suites[0]);return -EINVAL ; } - }else if (val & (WPA2_AUTH_PSK |WPA2_AUTH_UNSPECIFIED )) { + }else if (val & (WPA2_AUTH_PSK |WPA2_AUTH_UNSPECIFIED |WPA2_AUTH_1X_SHA256 )) {switch (sme->crypto.akm_suites[0 ]) {case WLAN_AKM_SUITE_8021X : val =WPA2_AUTH_UNSPECIFIED ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 146/609 amt: re-read skb header pointers after every pull
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Bommarito <[email protected]>
[ Upstream commit 3656a79f94c471827a08f2cacce5f94ad5e52c24 ]
Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head.
The affected sites are:
amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr.
amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address.
amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header.
amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them.
amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls.
amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac.
Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.
--- drivers/net/amt.c | 79 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 55 insertions(+), 24 deletions(-)
drivers/net/amt.c +55 -24
@@ -1206,7 +1206,7 @@ static netdev_tx_t amt_dev_xmit(struct sk_buff *skb, struct net_device *dev) data = true; } v6 = false; - group.ip4 = iph->daddr; + group.ip4 =ip_hdr (skb)->daddr;#if IS_ENABLED (CONFIG_IPV6 ) } else if (iph->version == 6) { ip6h =ipv6_hdr (skb);
@@ -1230,7 +1230,7 @@ static netdev_tx_t amt_dev_xmit(struct sk_buff *skb, struct net_device *dev) data = true; } v6 = true; - group.ip6 = ip6h->daddr; + group.ip6 =ipv6_hdr (skb)->daddr;#endif }else { dev->stats.tx_errors++;
@@ -1273,12 +1273,12 @@ static netdev_tx_t amt_dev_xmit(struct sk_buff *skb, struct net_device *dev)hlist_for_each_entry_rcu (gnode, &tunnel->groups[hash], node) {if (!v6) { -if (gnode->group_addr.ip4 == iph->daddr) +if (gnode->group_addr.ip4 == group.ip4) goto found;#if IS_ENABLED (CONFIG_IPV6 ) } else {if (ipv6_addr_equal (&gnode->group_addr.ip6, - &ip6h->daddr)) + &group.ip6)) goto found;#endif }
@@ -1995,14 +1995,18 @@ static void amt_igmpv3_report_handler(struct amt_dev *amt, struct sk_buff *skb,struct igmpv3_report *ihrv3 =igmpv3_report_hdr (skb);int len =skb_transport_offset (skb) +sizeof (*ihrv3);void *zero_grec = (void *)&igmpv3_zero_grec; -struct iphdr *iph =ip_hdr (skb);struct amt_group_node *gnode;union amt_addr group, host;struct igmpv3_grec *grec; +__be32 saddr;u16 nsrcs; +u16 ngrec;int i; -for (i =0 ; i <ntohs (ihrv3->ngrec); i++) { + saddr =ip_hdr (skb)->saddr; + ngrec =ntohs (ihrv3->ngrec); + +for (i =0 ; i < ngrec; i++) { len +=sizeof (*grec);if (!ip_mc_may_pull (skb, len))break ;
@@ -2014,10 +2018,13 @@ static void amt_igmpv3_report_handler(struct amt_dev *amt, struct sk_buff *skb,if (!ip_mc_may_pull (skb, len))break ; + grec = (void *)(skb->data + len -sizeof (*grec) - + nsrcs *sizeof (__be32)); +memset (&group,0 ,sizeof (union amt_addr )); group.ip4 = grec->grec_mca;memset (&host,0 ,sizeof (union amt_addr )); - host.ip4 = iph->saddr; + host.ip4 = saddr; gnode =amt_lookup_group (tunnel, &group, &host, false);if (!gnode) { gnode = amt_add_group(amt, tunnel, &group, &host,
@@ -2157,14 +2164,18 @@ static void amt_mldv2_report_handler(struct amt_dev *amt, struct sk_buff *skb,struct mld2_report *mld2r = (struct mld2_report *)icmp6_hdr (skb);int len =skb_transport_offset (skb) +sizeof (*mld2r);void *zero_grec = (void *)&mldv2_zero_grec; -struct ipv6hdr *ip6h =ipv6_hdr (skb);struct amt_group_node *gnode;union amt_addr group, host;struct mld2_grec *grec; +struct in6_addr saddr;u16 nsrcs; +u16 ngrec;int i; -for (i =0 ; i <ntohs (mld2r->mld2r_ngrec); i++) { + saddr =ipv6_hdr (skb)->saddr; + ngrec =ntohs (mld2r->mld2r_ngrec); + +for (i =0 ; i < ngrec; i++) { len +=sizeof (*grec);if (!ipv6_mc_may_pull (skb, len))break ;
@@ -2176,10 +2187,13 @@ static void amt_mldv2_report_handler(struct amt_dev *amt, struct sk_buff *skb,if (!ipv6_mc_may_pull (skb, len))break ; + grec = (void *)(skb->data + len -sizeof (*grec) - + nsrcs *sizeof (struct in6_addr )); +memset (&group,0 ,sizeof (union amt_addr )); group.ip6 = grec->grec_mca;memset (&host,0 ,sizeof (union amt_addr )); - host.ip6 = ip6h->saddr; + host.ip6 = saddr; gnode =amt_lookup_group (tunnel, &group, &host, true);if (!gnode) { gnode = amt_add_group(amt, tunnel, &group, &host,
@@ -2300,7 +2314,6 @@ static bool amt_multicast_data_handler(struct amt_dev *amt, struct sk_buff *skb)skb_push (skb,sizeof (*eth));skb_reset_mac_header (skb);skb_pull (skb,sizeof (*eth)); - eth =eth_hdr (skb);if (!pskb_may_pull (skb,sizeof (*iph)))return true;
@@ -2310,6 +2323,7 @@ static bool amt_multicast_data_handler(struct amt_dev *amt, struct sk_buff *skb)if (!ipv4_is_multicast (iph->daddr))return true; skb->protocol =htons (ETH_P_IP ); + eth =eth_hdr (skb); eth->h_proto =htons (ETH_P_IP );ip_eth_mc_map (iph->daddr, eth->h_dest);#if IS_ENABLED (CONFIG_IPV6 )
@@ -2323,6 +2337,7 @@ static bool amt_multicast_data_handler(struct amt_dev *amt, struct sk_buff *skb)if (!ipv6_addr_is_multicast (&ip6h->daddr))return true; skb->protocol =htons (ETH_P_IPV6 ); + eth =eth_hdr (skb); eth->h_proto =htons (ETH_P_IPV6 );ipv6_eth_mc_map (&ip6h->daddr, eth->h_dest);#endif
@@ -2346,10 +2361,12 @@ static bool amt_membership_query_handler(struct amt_dev *amt, struct sk_buff *skb) {struct amt_header_membership_query *amtmq; -struct igmpv3_query *ihv3;struct ethhdr *eth, *oeth; +struct igmpv3_query *ihv3; +u8 h_source[ETH_ALEN ];struct iphdr *iph;int hdr_size, len; +u64 response_mac; hdr_size =sizeof (*amtmq) +sizeof (struct udphdr );if (!pskb_may_pull (skb, hdr_size))
@@ -2362,6 +2379,8 @@ static bool amt_membership_query_handler(struct amt_dev *amt,if (amtmq->nonce != amt->nonce)return true; + response_mac = amtmq->response_mac; + hdr_size -=sizeof (*eth);if (iptunnel_pull_header (skb, hdr_size,htons (ETH_P_TEB ), false))return true;
@@ -2371,6 +2390,7 @@ static bool amt_membership_query_handler(struct amt_dev *amt,skb_pull (skb,sizeof (*eth));skb_reset_network_header (skb); eth =eth_hdr (skb); +ether_addr_copy (h_source, oeth->h_source);if (!pskb_may_pull (skb,sizeof (*iph)))return true;
@@ -2383,6 +2403,7 @@ static bool amt_membership_query_handler(struct amt_dev *amt, sizeof(*ihv3)))return true; + iph =ip_hdr (skb);if (!ipv4_is_multicast (iph->daddr))return true;
@@ -2390,10 +2411,11 @@ static bool amt_membership_query_handler(struct amt_dev *amt,skb_reset_transport_header (skb);skb_push (skb,sizeof (*iph) +AMT_IPHDR_OPTS );WRITE_ONCE (amt->ready4, true); - amt->mac = amtmq->response_mac; + amt->mac = response_mac; amt->req_cnt =0 ; amt->qi = ihv3->qqic; skb->protocol =htons (ETH_P_IP ); + eth =eth_hdr (skb); eth->h_proto =htons (ETH_P_IP );ip_eth_mc_map (iph->daddr, eth->h_dest);#if IS_ENABLED (CONFIG_IPV6 )
@@ -2416,10 +2438,11 @@ static bool amt_membership_query_handler(struct amt_dev *amt,skb_reset_transport_header (skb);skb_push (skb,sizeof (*ip6h) +AMT_IP6HDR_OPTS );WRITE_ONCE (amt->ready6, true); - amt->mac = amtmq->response_mac; + amt->mac = response_mac; amt->req_cnt =0 ; amt->qi = mld2q->mld2q_qqic; skb->protocol =htons (ETH_P_IPV6 ); + eth =eth_hdr (skb); eth->h_proto =htons (ETH_P_IPV6 );ipv6_eth_mc_map (&ip6h->daddr, eth->h_dest);#endif
@@ -2427,7 +2450,7 @@ static bool amt_membership_query_handler(struct amt_dev *amt,return true; } -ether_addr_copy (eth->h_source, oeth->h_source); +ether_addr_copy (eth->h_source, h_source); skb->pkt_type =PACKET_MULTICAST ; skb->ip_summed =CHECKSUM_NONE ; len = skb->len;
@@ -2450,8 +2473,11 @@ static bool amt_update_handler(struct amt_dev *amt, struct sk_buff *skb)struct ethhdr *eth;struct iphdr *iph;int len, hdr_size; +u64 response_mac; +__be32 saddr; +__be32 nonce; - iph =ip_hdr (skb); + saddr =ip_hdr (skb)->saddr; hdr_size =sizeof (*amtmu) +sizeof (struct udphdr );if (!pskb_may_pull (skb, hdr_size))
@@ -2461,15 +2487,18 @@ static bool amt_update_handler(struct amt_dev *amt, struct sk_buff *skb)if (amtmu->reserved || amtmu->version)return true; + nonce = amtmu->nonce; + response_mac = amtmu->response_mac; +if (iptunnel_pull_header (skb, hdr_size, skb->protocol, false))return true;skb_reset_network_header (skb);list_for_each_entry_rcu (tunnel, &amt->tunnel_list, list) { -if (tunnel->ip4 == iph->saddr) { -if ((amtmu->nonce == tunnel->nonce && - amtmu->response_mac == tunnel->mac)) { +if (tunnel->ip4 == saddr) { +if ((nonce == tunnel->nonce && + response_mac == tunnel->mac)) {mod_delayed_work (amt_wq, &tunnel->gc_wq,msecs_to_jiffies (amt_gmi (amt)) *3 );
@@ -2503,6 +2532,7 @@ static bool amt_update_handler(struct amt_dev *amt, struct sk_buff *skb) eth =eth_hdr (skb); skb->protocol =htons (ETH_P_IP ); eth->h_proto =htons (ETH_P_IP ); + iph =ip_hdr (skb);ip_eth_mc_map (iph->daddr, eth->h_dest);#if IS_ENABLED (CONFIG_IPV6 ) } else if (iph->version == 6) {
@@ -2522,6 +2552,7 @@ static bool amt_update_handler(struct amt_dev *amt, struct sk_buff *skb) eth =eth_hdr (skb); skb->protocol =htons (ETH_P_IPV6 ); eth->h_proto =htons (ETH_P_IPV6 ); + ip6h =ipv6_hdr (skb);ipv6_eth_mc_map (&ip6h->daddr, eth->h_dest);#endif }else {
@@ -2767,7 +2798,7 @@ static void amt_gw_rcv(struct amt_dev *amt, struct sk_buff *skb)static int amt_rcv (struct sock *sk,struct sk_buff *skb) {struct amt_dev *amt; -struct iphdr *iph; +__be32 saddr;int type;bool err;
@@ -2780,7 +2811,7 @@ static int amt_rcv(struct sock *sk, struct sk_buff *skb) } skb->dev = amt->dev; - iph =ip_hdr (skb); + saddr =ip_hdr (skb)->saddr; type =amt_parse_type (skb);if (type ==-1 ) { err = true;
@@ -2790,7 +2821,7 @@ static int amt_rcv(struct sock *sk, struct sk_buff *skb)if (amt->mode ==AMT_MODE_GATEWAY ) {switch (type) {case AMT_MSG_ADVERTISEMENT : -if (iph->saddr != amt->discovery_ip) { +if (saddr != amt->discovery_ip) {netdev_dbg (amt->dev,"Invalid Relay IP\n" ); err = true; goto drop;
@@ -2802,7 +2833,7 @@ static int amt_rcv(struct sock *sk, struct sk_buff *skb) } goto out;case AMT_MSG_MULTICAST_DATA : -if (iph->saddr != amt->remote_ip) { +if (saddr != amt->remote_ip) {netdev_dbg (amt->dev,"Invalid Relay IP\n" ); err = true; goto drop;
@@ -2813,7 +2844,7 @@ static int amt_rcv(struct sock *sk, struct sk_buff *skb)else goto out;case AMT_MSG_MEMBERSHIP_QUERY : -if (iph->saddr != amt->remote_ip) { +if (saddr != amt->remote_ip) {netdev_dbg (amt->dev,"Invalid Relay IP\n" ); err = true; goto drop;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 147/609 amt: make the head writable before rewriting the L2 header
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Bommarito <[email protected]>
[ Upstream commit 53969d704fa5b7c1751e277fac96bfc22b435eac ]
amt_multicast_data_handler(), amt_membership_query_handler() and amt_update_handler() rewrite the ethernet header of the decapsulated skb in place (eth->h_proto, eth->h_dest and, for the query, also eth->h_source) before handing it up the stack. The skb head may be shared, for example when a packet tap has cloned it on the underlay interface, so writing through it corrupts the other reader's copy.
Call skb_cow_head() before the rewrite so the head is private. It is placed before the pointers into the head are (re-)derived, so a reallocation caused by the copy is picked up by those derivations.
--- drivers/net/amt.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/net/amt.c +8 -0
@@ -2315,6 +2315,9 @@ static bool amt_multicast_data_handler(struct amt_dev *amt, struct sk_buff *skb)skb_reset_mac_header (skb);skb_pull (skb,sizeof (*eth)); +if (skb_cow_head (skb,0 )) +return true; +if (!pskb_may_pull (skb,sizeof (*iph)))return true; iph =ip_hdr (skb);
@@ -2391,6 +2394,8 @@ static bool amt_membership_query_handler(struct amt_dev *amt,skb_reset_network_header (skb); eth =eth_hdr (skb);ether_addr_copy (h_source, oeth->h_source); +if (skb_cow_head (skb,0 )) +return true;if (!pskb_may_pull (skb,sizeof (*iph)))return true;
@@ -2516,6 +2521,9 @@ static bool amt_update_handler(struct amt_dev *amt, struct sk_buff *skb)if (!pskb_may_pull (skb,sizeof (*iph)))return true; +if (skb_cow_head (skb,0 )) +return true; + iph =ip_hdr (skb);if (iph->version ==4 ) {if (ip_mc_check_igmp (skb)) {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 148/609 net: bridge: vlan: fix vlan range dumps starting with pvid
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikolay Aleksandrov <[email protected]>
[ Upstream commit 43171c97e4714bf601b468401b37732244639c21 ]
There is a bug in all range dumps that rely on br_vlan_can_enter_range() when the PVID is a range starting VLAN, all following VLANs that match its flags can enter the range, but when the range is filled in only the PVID VLAN is dumped and the rest of the range is discarded because br_vlan_fill_vids() checks for the PVID flag. Since the PVID VLAN can be only one, we need to break ranges around it, the best way to do that consistently for all is to alter br_vlan_can_enter_range() to take into account the PVID and return false to break the range when it's matched.
Before the fix:
$ ip l add br0 type bridge vlan_filtering 1
$ ip l add dumdum type dummy
$ ip l set dumdum master br0
$ ip l set br0 up
$ ip l set dumdum up
$ bridge vlan add dev dumdum vid 1 pvid untagged master
$ bridge vlan add dev dumdum vid 2 untagged master
$ bridge vlan show dev dumdum # use legacy dump to show all vlans
port vlan-id
dumdum 1 PVID Egress Untagged
2 Egress Untagged$ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN)
port vlan-id
dumdum 1 PVID Egress Untagged
state forwarding mcast_router 1VLAN 2 is missing, and if there are more matching VLANs afterwards they'd be missing too.
After the fix:
[ same setup steps ]
$ bridge vlan show dev dumdum
port vlan-id
dumdum 1 PVID Egress Untagged
2 Egress Untagged
$ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN)
port vlan-id
dumdum 1 PVID Egress Untagged
state forwarding mcast_router 1
2 Egress Untagged
state forwarding mcast_router 1--- net/bridge/br_netlink_tunnel.c | 3 ++- net/bridge/br_private.h | 6 ++++-- net/bridge/br_vlan.c | 10 ++++++---- net/bridge/br_vlan_options.c | 3 +-- 4 files changed, 13 insertions(+), 9 deletions(-)
net/bridge/br_netlink_tunnel.c +2 -1
@@ -268,7 +268,8 @@ static void __vlan_tunnel_handle_range(const struct net_bridge_port *p,if (!*v_start) goto out_init; -if (v && curr_change &&br_vlan_can_enter_range (v, *v_end)) { +if (v && curr_change && +br_vlan_can_enter_range (v, *v_end,br_get_pvid (vg))) { *v_end = v;return ; }
net/bridge/br_private.h +4 -2
@@ -1487,7 +1487,8 @@ void br_vlan_notify(const struct net_bridge *br, u16 vid, u16 vid_range, int cmd);bool br_vlan_can_enter_range (const struct net_bridge_vlan *v_curr, -const struct net_bridge_vlan *range_end); +const struct net_bridge_vlan *range_end, +u16 pvid); void br_vlan_fill_forward_path_pvid(struct net_bridge *br, struct net_device_path_ctx *ctx,
@@ -1727,7 +1728,8 @@ static inline void br_vlan_notify(const struct net_bridge *br, }static inline bool br_vlan_can_enter_range (const struct net_bridge_vlan *v_curr, -const struct net_bridge_vlan *range_end) +const struct net_bridge_vlan *range_end, +u16 pvid) {return true; }
net/bridge/br_vlan.c +6 -4
@@ -1942,9 +1942,11 @@ void br_vlan_notify(const struct net_bridge *br,/* check if v_curr can enter a range ending in range_end */ bool br_vlan_can_enter_range (const struct net_bridge_vlan *v_curr, -const struct net_bridge_vlan *range_end) +const struct net_bridge_vlan *range_end, +u16 pvid) { -return v_curr->vid - range_end->vid ==1 && +return v_curr->vid != pvid && range_end->vid != pvid && + v_curr->vid - range_end->vid ==1 && range_end->flags == v_curr->flags &&br_vlan_opts_eq_range (v_curr, range_end); }
@@ -2026,8 +2028,8 @@ static int br_vlan_dump_dev(const struct net_device *dev, idx += range_end->vid - range_start->vid +1 ; range_start = v; - } else if (dump_stats || v->vid == pvid || - !br_vlan_can_enter_range(v, range_end)) { + } else if (dump_stats || + !br_vlan_can_enter_range(v, range_end, pvid)) { u16 vlan_flags = br_vlan_flags(range_start, pvid); if (!br_vlan_fill_vids(skb, range_start->vid,
net/bridge/br_vlan_options.c +1 -2
@@ -267,8 +267,7 @@ int br_vlan_process_options(const struct net_bridge *br,continue ; } -if (v->vid == pvid || - !br_vlan_can_enter_range (v, curr_end)) { +if (!br_vlan_can_enter_range (v, curr_end, pvid)) {br_vlan_notify (br, p, curr_start->vid, curr_end->vid,RTM_NEWVLAN ); curr_start = v;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 149/609 net: hsr: fix memory leak on slave unregistration by removing synced VLANs
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit dcf15eaf5641812f1cfc5e96537380132a7da89d ]
When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B).
If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR.
As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak.
Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.
--- net/hsr/hsr_slave.c | 2 ++ 1 file changed, 2 insertions(+)
net/hsr/hsr_slave.c +2 -0
@@ -228,6 +228,8 @@ void hsr_del_port(struct hsr_port *port)netdev_rx_handler_unregister (port->dev);if (!port->hsr->fwd_offloaded)dev_set_promiscuity (port->dev,-1 ); +if (port->type ==HSR_PT_SLAVE_A || port->type ==HSR_PT_SLAVE_B ) +vlan_vids_del_by_dev (port->dev, master->dev);netdev_upper_dev_unlink (port->dev, master->dev); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 150/609 sctp: auth: verify auth requirement when auth_chunk is NULL
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qing Luo <[email protected]>
[ Upstream commit 8e04823c120b376ef7dab14b60ebf6823aa16c14 ]
sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when:
1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this.
2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL.
Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL:
if authentication is required, return false to drop the chunk; otherwise continue normally.
--- net/sctp/sm_statefuns.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/sctp/sm_statefuns.c +1 -1
@@ -640,7 +640,7 @@ static bool sctp_auth_chunk_verify(struct net *net, struct sctp_chunk *chunk,struct sctp_chunk auth;if (!chunk->auth_chunk) -return true; +return !sctp_auth_recv_cid (chunk->chunk_hdr->type, asoc);/* SCTP-AUTH: auth_chunk pointer is only set when the cookie-echo * is supposed to be authenticated and we have to do delayed
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 151/609 vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harshaka Narayana <[email protected]>
[ Upstream commit 34a71f5361fc3adb5b7138da78750b0d535a8252 ]
vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers:
- BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP.
- BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa).
Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.
--- drivers/net/vmxnet3/vmxnet3_drv.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)
drivers/net/vmxnet3/vmxnet3_drv.c +16 -6
@@ -1365,7 +1365,11 @@ vmxnet3_get_hdr_len(struct vmxnet3_adapter *adapter, struct sk_buff *skb,struct ipv6hdr *ipv6;struct tcphdr *tcp; } hdr; -BUG_ON (gdesc->rcd.tcp ==0 ); + +/* v4/v6/tcp then describe the inner header, which we can't locate. */ +if ((le32_to_cpu (gdesc->dword[0 ]) & (1UL <<VMXNET3_RCD_HDR_INNER_SHIFT )) || + gdesc->rcd.tcp ==0 ) +return 0 ; maplen =skb_headlen (skb);if (unlikely (sizeof (struct iphdr ) +sizeof (struct tcphdr ) > maplen))
@@ -1379,15 +1383,21 @@ vmxnet3_get_hdr_len(struct vmxnet3_adapter *adapter, struct sk_buff *skb, hdr.eth =eth_hdr (skb);if (gdesc->rcd.v4) { -BUG_ON (hdr.eth->h_proto !=htons (ETH_P_IP ) && - hdr.veth->h_vlan_encapsulated_proto !=htons (ETH_P_IP )); +if (hdr.eth->h_proto !=htons (ETH_P_IP ) && + hdr.veth->h_vlan_encapsulated_proto !=htons (ETH_P_IP )) +return 0 ; + hdr.ptr += hlen; -BUG_ON (hdr.ipv4->protocol !=IPPROTO_TCP ); +if (hdr.ipv4->protocol !=IPPROTO_TCP ) +return 0 ; + hlen = hdr.ipv4->ihl <<2 ; hdr.ptr += hdr.ipv4->ihl <<2 ; }else if (gdesc->rcd.v6) { -BUG_ON (hdr.eth->h_proto !=htons (ETH_P_IPV6 ) && - hdr.veth->h_vlan_encapsulated_proto !=htons (ETH_P_IPV6 )); +if (hdr.eth->h_proto !=htons (ETH_P_IPV6 ) && + hdr.veth->h_vlan_encapsulated_proto !=htons (ETH_P_IPV6 )) +return 0 ; + hdr.ptr += hlen;/* Use an estimated value, since we also need to handle * TSO case.
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 152/609 tipc: fix u16 MTU truncation in media and bearer MTU validation
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cen Zhang (Microsoft) <[email protected]>
[ Upstream commit 9f29cd8a8e7901a2617c8064ce9f50fc67b97cb8 ]
Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors.
Crash stack (triggered as unprivileged user via user namespace):
tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392
Two independent paths lack the upper bound check:
1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET)
2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET)
Fix both by rejecting MTU values above U16_MAX.
--- net/tipc/netlink.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/tipc/netlink.c +5 -1
@@ -113,12 +113,16 @@ const struct nla_policy tipc_nl_node_pol };/* Properties valid for media, bearer and link */ +static struct netlink_range_validation tipc_nl_mtu_range = { + .max =U16_MAX , +}; +const struct nla_policy tipc_nl_prop_policy[TIPC_NLA_PROP_MAX +1 ] = { [TIPC_NLA_PROP_UNSPEC ] = { .type =NLA_UNSPEC }, [TIPC_NLA_PROP_PRIO ] = { .type =NLA_U32 }, [TIPC_NLA_PROP_TOL ] = { .type =NLA_U32 }, [TIPC_NLA_PROP_WIN ] = { .type =NLA_U32 }, - [TIPC_NLA_PROP_MTU ] = { .type =NLA_U32 }, + [TIPC_NLA_PROP_MTU ] =NLA_POLICY_FULL_RANGE (NLA_U32 , &tipc_nl_mtu_range), [TIPC_NLA_PROP_BROADCAST ] = { .type =NLA_U32 }, [TIPC_NLA_PROP_BROADCAST_RATIO ] = { .type =NLA_U32 } };
Greg Kroah-Hartman
maintainerPATCH 153/609 net: stmmac: fix l3l4 filter rejecting unsupported offload requests
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nazim Amirul <[email protected]>
[ Upstream commit 5536d7c843637e9430279b94935fcf7df98babb3 ]
The basic flow parser in tc_add_basic_flow() does not validate match keys before proceeding. Unsupported offload configurations such as partial protocol masks, non-IPv4 network proto, or non-TCP/UDP transport proto are silently accepted instead of returning -EOPNOTSUPP.
Add validation to return -EOPNOTSUPP early for:
- No network or transport proto present in the key
- Partial protocol mask (only full mask supported)
- Network proto is not IPv4
- Transport proto is not TCP or UDP
Each rejection includes an extack message so the user knows which part of the match is unsupported.
Also propagate -EOPNOTSUPP from tc_add_basic_flow() in tc_add_flow() by returning it directly rather than using break. The break was silently discarding the error for FLOW_CLS_REPLACE operations where entry->in_use is already true, causing tc_add_flow() to return 0 (success) for unsupported replace requests.
--- .../net/ethernet/stmicro/stmmac/stmmac_tc.c | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+)
drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c +34 -0
@@ -456,6 +456,7 @@ static int tc_parse_flow_actions(struct stmmac_priv *priv, }#define ETHER_TYPE_FULL_MASK cpu_to_be16(~0) +#define IP_PROTO_FULL_MASK 0xFF static int tc_add_basic_flow(struct stmmac_priv *priv, struct flow_cls_offload *cls,
@@ -471,6 +472,37 @@ static int tc_add_basic_flow(struct stmmac_priv *priv,flow_rule_match_basic (rule, &match); +/* Both network proto and transport proto not present in the key */ +if (!match.mask || !(match.mask->n_proto || match.mask->ip_proto)) { +NL_SET_ERR_MSG_MOD (cls->common.extack, +"filter must specify network or transport protocol" ); +return -EOPNOTSUPP ; + } + +/* If the proto is present in the key and is not full mask */ +if ((match.mask->n_proto && match.mask->n_proto !=ETHER_TYPE_FULL_MASK ) || + (match.mask->ip_proto && match.mask->ip_proto !=IP_PROTO_FULL_MASK )) { +NL_SET_ERR_MSG_MOD (cls->common.extack, +"only full protocol mask is supported" ); +return -EOPNOTSUPP ; + } + +/* Network proto is present in the key and is not IPv4 */ +if (match.mask->n_proto && match.key->n_proto !=cpu_to_be16 (ETH_P_IP )) { +NL_SET_ERR_MSG_MOD (cls->common.extack, +"only IPv4 network protocol is supported" ); +return -EOPNOTSUPP ; + } + +/* Transport proto is present in the key and is not TCP or UDP */ +if (match.mask->ip_proto && + match.key->ip_proto !=IPPROTO_TCP && + match.key->ip_proto !=IPPROTO_UDP ) { +NL_SET_ERR_MSG_MOD (cls->common.extack, +"only TCP and UDP transport protocols are supported" ); +return -EOPNOTSUPP ; + } + entry->ip_proto = match.key->ip_proto;return 0 ; }
@@ -608,6 +640,8 @@ static int tc_add_flow(struct stmmac_priv *priv, ret = tc_flow_parsers[i].fn (priv, cls, entry);if (!ret) entry->in_use = true; +else if (ret == -EOPNOTSUPP ) +return ret; }if (!entry->in_use)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 154/609 net: stmmac: reset residual action in L3L4 filters on delete
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nazim Amirul <[email protected]>
[ Upstream commit a448f821289934b961dd9d8d0beb006cc8937ba2 ]
When deleting an L3/L4 flower filter entry, the action field is not reset. If a filter was previously configured with a drop action, that action may persist and affect subsequent filter configurations unintentionally.
Clear the action field when the filter entry is deleted.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c +1 -0
@@ -671,6 +671,7 @@ static int tc_del_flow(struct stmmac_priv *priv, entry->in_use = false; entry->cookie =0 ; entry->is_l4 = false; + entry->action =0 ;return ret; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 155/609 octeontx2-vf: set TC flower flag on MCAM entry allocation
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Suman Ghosh <[email protected]>
[ Upstream commit 0d4d31e3cc5dd6204fa1495c4107f5075acce5ed ]
When MCAM entries are allocated for a VF netdev via the devlink mcam_count parameter, only OTX2_FLAG_NTUPLE_SUPPORT was set. That enabled ethtool ntuple filters but not tc flower offload. Also set OTX2_FLAG_TC_FLOWER_SUPPORT when entries are successfully allocated.
--- drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c +1 -0
@@ -153,6 +153,7 @@ int otx2_alloc_mcam_entries(struct otx2_nic *pfvf, u16 count)if (allocated) { pfvf->flags |=OTX2_FLAG_MCAM_ENTRIES_ALLOC ; pfvf->flags |=OTX2_FLAG_NTUPLE_SUPPORT ; + pfvf->flags |=OTX2_FLAG_TC_FLOWER_SUPPORT ; }if (allocated != count)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 156/609 ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 853e164c2b321f0711361bc23505aaeb7dc432c3 ]
When Linux forwards a packet and needs to generate an ICMP error, icmp_route_lookup() performs a reverse-path relookup. For non-local destinations, it performs a decoy lookup to find the expected egress interface (rt2->dst.dev) before validating the path with ip_route_input().
Currently, the decoy flow structure (fl4_2) only sets .daddr = fl4_dec.saddr, leaving .saddr, .flowi4_dscp, .flowi4_proto, .flowi4_mark, .flowi4_oif, .fl4_sport, .fl4_dport, and .flowi4_uid zeroed out.
When policy routing rules (such as ip rule add from $SRC lookup 100, or dscp/fwmark/ipproto/port rules, or VRF bindings) are configured:
1. The decoy lookup fails to match the policy rule because saddr and other key flow selectors are missing in fl4_2.
2. It resolves a route using the default table instead, returning an incorrect egress netdev.
3. Passing the wrong netdev to ip_route_input() causes strict reverse-path filtering (rp_filter=1) to fail, logging false-positive "martian source" warnings and causing the relookup to fail.
Fix this by initializing fl4_2 from fl4_dec and:
- Swapping source/destination IP addresses.
- Swapping L4 ports for transport protocols with ports (TCP, UDP, SCTP, DCCP) so port-based policy routing matches correctly. Non-port protocols (such as ICMP or GRE) leave the flowi_uli union fields intact to prevent corruption.
- Setting .flowi4_oif = l3mdev_master_ifindex(route_lookup_dev) to ensure VRF routing tables are respected.
- Setting .flowi4_flags |= FLOWI_FLAG_ANYSRC to allow output route lookups for non-local source IP addresses.
- Using __ip_route_output_key() instead of ip_route_output_key() for fl4_2 so that raw FIB routing is used without triggering spurious XFRM policy lookups on the decoy flow (the actual XFRM lookup is performed later using fl4_dec).
--- net/ipv4/icmp.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-)
net/ipv4/icmp.c +15 -3
@@ -536,11 +536,23 @@ static struct rtable *icmp_route_lookup(struct net *net, struct flowi4 *fl4,if (IS_ERR (rt2)) err =PTR_ERR (rt2); }else { -struct flowi4 fl4_2 = {}; +struct flowi4 fl4_2 = fl4_dec;unsigned long orefdst; - fl4_2.daddr = fl4_dec.saddr; - rt2 =ip_route_output_key (net, &fl4_2); +swap (fl4_2.daddr, fl4_2.saddr); +switch (fl4_2.flowi4_proto) { +case IPPROTO_TCP : +case IPPROTO_UDP : +case IPPROTO_SCTP : +case IPPROTO_DCCP : +swap (fl4_2.fl4_sport, fl4_2.fl4_dport); +break ; + } + + fl4_2.flowi4_oif =l3mdev_master_ifindex (route_lookup_dev); + fl4_2.flowi4_flags |=FLOWI_FLAG_ANYSRC ; + + rt2 =__ip_route_output_key (net, &fl4_2);if (IS_ERR (rt2)) { err =PTR_ERR (rt2); goto relookup_failed;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 157/609 ppp: use IFF_NO_QUEUE in virtual interfaces
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qingfang Deng <[email protected]>
[ Upstream commit 95d0d094ba26432ec467e2260f4bf553053f1f8f ]
For PPPoE, PPTP, and PPPoL2TP, the start_xmit() function directly forwards packets to the underlying network stack and never returns anything other than 1. So these interfaces do not require a qdisc, and the IFF_NO_QUEUE flag should be set.
Introduces a direct_xmit flag in struct ppp_channel to indicate when IFF_NO_QUEUE should be applied. The flag is set in ppp_connect_channel() for relevant protocols.
While at it, remove the usused latency member from struct ppp_channel.
Stable-dep-of: 543adf072165 ("ppp: annotate data races in ppp_generic")
--- drivers/net/ppp/ppp_generic.c | 4 ++++ drivers/net/ppp/pppoe.c | 1 + drivers/net/ppp/pptp.c | 1 + include/linux/ppp_channel.h | 3 +-- net/l2tp/l2tp_ppp.c | 1 + 5 files changed, 8 insertions(+), 2 deletions(-)
drivers/net/ppp/ppp_generic.c +4 -0
@@ -3508,6 +3508,10 @@ ppp_connect_channel(struct channel *pch, int unit) ret = -ENOTCONN ; goto outl; } +if (pch->chan->direct_xmit) + ppp->dev->priv_flags |=IFF_NO_QUEUE ; +else + ppp->dev->priv_flags &= ~IFF_NO_QUEUE ;spin_unlock_bh (&pch->downl);if (pch->file.hdrlen > ppp->file.hdrlen) ppp->file.hdrlen = pch->file.hdrlen;
drivers/net/ppp/pppoe.c +1 -0
@@ -699,6 +699,7 @@ static int pppoe_connect(struct socket *sock, struct sockaddr *uservaddr, po->chan.mtu = dev->mtu -sizeof (struct pppoe_hdr ) -2 ; po->chan.private = sk; po->chan.ops = &pppoe_chan_ops; + po->chan.direct_xmit = true; error =ppp_register_net_channel (dev_net (dev), &po->chan);if (error) {
drivers/net/ppp/pptp.c +1 -0
@@ -469,6 +469,7 @@ static int pptp_connect(struct socket *sock, struct sockaddr *uservaddr, po->chan.mtu -=PPTP_HEADER_OVERHEAD ; po->chan.hdrlen =2 +sizeof (struct pptp_gre_header ); + po->chan.direct_xmit = true; error =ppp_register_channel (&po->chan);if (error) {pr_err ("PPTP: failed to register PPP channel (%d)\n" , error);
include/linux/ppp_channel.h +1 -2
@@ -42,8 +42,7 @@ struct ppp_channel {int hdrlen;/* amount of headroom channel needs */ void *ppp;/* opaque to channel */ int speed;/* transfer rate (bytes/second) */ -/* the following is not used at present */ -int latency;/* overhead time in milliseconds */ +bool direct_xmit;/* no qdisc, xmit directly */ };#ifdef __KERNEL__
net/l2tp/l2tp_ppp.c +1 -0
@@ -810,6 +810,7 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr, po->chan.private = sk; po->chan.ops = &pppol2tp_chan_ops; po->chan.mtu =pppol2tp_tunnel_mtu (tunnel); + po->chan.direct_xmit = true; error =ppp_register_net_channel (sock_net (sk), &po->chan);if (error) {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 158/609 ppp: convert to percpu netstats
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qingfang Deng <[email protected]>
[ Upstream commit 1a3e9b7a6b09e8ab3d2af019e4a392622685855e ]
Convert to percpu netstats to avoid lock contention when reading them.
Stable-dep-of: 543adf072165 ("ppp: annotate data races in ppp_generic")
--- drivers/net/ppp/ppp_generic.c | 52 +++++++++++++---------------------- 1 file changed, 19 insertions(+), 33 deletions(-)
drivers/net/ppp/ppp_generic.c +19 -33
@@ -107,18 +107,6 @@ struct ppp_file {#define PF_TO_PPP (pf) PF_TO_X(pf, struct ppp)#define PF_TO_CHANNEL (pf) PF_TO_X(pf, struct channel) -/* -* Data structure to hold primary network stats for which -* we want to use 64 bit storage. Other network stats -* are stored in dev->stats of the ppp strucute. -*/ -struct ppp_link_stats { -u64 rx_packets; -u64 tx_packets; -u64 rx_bytes; -u64 tx_bytes; -}; -/* * Data structure describing one ppp unit. * A ppp unit corresponds to a ppp network interface device
@@ -162,7 +150,6 @@ struct ppp {struct bpf_prog *active_filter;/* filter for pkts to reset idle */ #endif /* CONFIG_PPP_FILTER */ struct net *ppp_net;/* the net we belong to */ -struct ppp_link_stats stats64;/* 64 bit network stats */ };/*
@@ -1545,23 +1532,12 @@ ppp_net_siocdevprivate(struct net_device *dev, struct ifreq *ifr,static void ppp_get_stats64 (struct net_device *dev,struct rtnl_link_stats64 *stats64) { -struct ppp *ppp =netdev_priv (dev); - -ppp_recv_lock (ppp); - stats64->rx_packets = ppp->stats64.rx_packets; - stats64->rx_bytes = ppp->stats64.rx_bytes; -ppp_recv_unlock (ppp); - -ppp_xmit_lock (ppp); - stats64->tx_packets = ppp->stats64.tx_packets; - stats64->tx_bytes = ppp->stats64.tx_bytes; -ppp_xmit_unlock (ppp); - stats64->rx_errors = dev->stats.rx_errors; stats64->tx_errors = dev->stats.tx_errors; stats64->rx_dropped = dev->stats.rx_dropped; stats64->tx_dropped = dev->stats.tx_dropped; stats64->rx_length_errors = dev->stats.rx_length_errors; +dev_fetch_sw_netstats (stats64, dev->tstats); }static int ppp_dev_init (struct net_device *dev)
@@ -1659,6 +1635,7 @@ static void ppp_setup(struct net_device *dev) dev->type =ARPHRD_PPP ; dev->flags =IFF_POINTOPOINT |IFF_NOARP |IFF_MULTICAST ; dev->priv_destructor = ppp_dev_priv_destructor; + dev->pcpu_stat_type =NETDEV_PCPU_STAT_TSTATS ;netif_keep_dst (dev); }
@@ -1804,8 +1781,7 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)#endif /* CONFIG_PPP_FILTER */ } - ++ppp->stats64.tx_packets; - ppp->stats64.tx_bytes += skb->len -PPP_PROTO_LEN ; +dev_sw_netstats_tx_add (ppp->dev,1 , skb->len -PPP_PROTO_LEN );switch (proto) {case PPP_IP :
@@ -2483,8 +2459,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)break ; } - ++ppp->stats64.rx_packets; - ppp->stats64.rx_bytes += skb->len -2 ; +dev_sw_netstats_rx_add (ppp->dev, skb->len -PPP_PROTO_LEN ); npi =proto_to_npindex (proto);if (npi <0 ) {
@@ -3312,14 +3287,25 @@ static void ppp_get_stats(struct ppp *ppp, struct ppp_stats *st) { struct slcompress *vj = ppp->vj; +int cpu;memset (st,0 ,sizeof (*st)); - st->p.ppp_ipackets = ppp->stats64.rx_packets; +for_each_possible_cpu (cpu) { +struct pcpu_sw_netstats *p =per_cpu_ptr (ppp->dev->tstats, cpu); +u64 rx_packets, rx_bytes, tx_packets, tx_bytes; + + rx_packets =u64_stats_read (&p->rx_packets); + rx_bytes =u64_stats_read (&p->rx_bytes); + tx_packets =u64_stats_read (&p->tx_packets); + tx_bytes =u64_stats_read (&p->tx_bytes); + + st->p.ppp_ipackets += rx_packets; + st->p.ppp_ibytes += rx_bytes; + st->p.ppp_opackets += tx_packets; + st->p.ppp_obytes += tx_bytes; + } st->p.ppp_ierrors = ppp->dev->stats.rx_errors; - st->p.ppp_ibytes = ppp->stats64.rx_bytes; - st->p.ppp_opackets = ppp->stats64.tx_packets; st->p.ppp_oerrors = ppp->dev->stats.tx_errors; - st->p.ppp_obytes = ppp->stats64.tx_bytes;if (!vj)return ; st->vj.vjs_packets = vj->sls_o_compressed + vj->sls_o_uncompressed;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 159/609 ppp: enable TX scatter-gather
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qingfang Deng <[email protected]>
[ Upstream commit 42fcb213e58a7da33d5d2d7517b4e521025c68c3 ]
PPP channels using chan->direct_xmit prepend the PPP header to a skb and call dev_queue_xmit() directly. In this mode the skb does not need to be linear, but the PPP netdevice currently does not advertise scatter-gather features, causing unnecessary linearization and preventing GSO.
Enable NETIF_F_SG and NETIF_F_FRAGLIST on PPP devices. In case a linear buffer is required (PPP compression, multilink, and channels without direct_xmit), call skb_linearize() explicitly.
Stable-dep-of: 543adf072165 ("ppp: annotate data races in ppp_generic")
--- drivers/net/ppp/ppp_generic.c | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-)
drivers/net/ppp/ppp_generic.c +25 -5
@@ -1636,6 +1636,8 @@ static void ppp_setup(struct net_device *dev) dev->flags =IFF_POINTOPOINT |IFF_NOARP |IFF_MULTICAST ; dev->priv_destructor = ppp_dev_priv_destructor; dev->pcpu_stat_type =NETDEV_PCPU_STAT_TSTATS ; + dev->features =NETIF_F_SG |NETIF_F_FRAGLIST ; + dev->hw_features = dev->features;netif_keep_dst (dev); }
@@ -1700,6 +1702,10 @@ pad_compress_skb(struct ppp *ppp, struct sk_buff *skb) ppp->xcomp->comp_extra + ppp->dev->hard_header_len;int compressor_skb_size = ppp->dev->mtu + ppp->xcomp->comp_extra +PPP_HDRLEN ; + +if (skb_linearize (skb)) +return NULL ; + new_skb =alloc_skb (new_skb_size,GFP_ATOMIC );if (!new_skb) {if (net_ratelimit ())
@@ -1787,6 +1793,10 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)case PPP_IP :if (!ppp->vj || (ppp->flags &SC_COMP_TCP ) ==0 )break ; + +if (skb_linearize (skb)) + goto drop; +/* try to do VJ TCP header compression */ new_skb =alloc_skb (skb->len + ppp->dev->hard_header_len -2 ,GFP_ATOMIC );
@@ -1884,19 +1894,26 @@ ppp_push(struct ppp *ppp) }if ((ppp->flags &SC_MULTILINK ) ==0 ) { +struct ppp_channel *chan;/* not doing multilink: send it down the first channel */ list = list->next; pch = list_entry(list, struct channel, clist);spin_lock (&pch->downl); -if (pch->chan) { -if (pch->chan->ops->start_xmit (pch->chan, skb)) - ppp->xmit_pending =NULL ; - }else { -/* channel got unregistered */ + chan = pch->chan; +if (unlikely (!chan || (!chan->direct_xmit &&skb_linearize (skb)))) { +/* channel got unregistered, or it requires a linear +* skb but linearization failed +*/ kfree_skb (skb); ppp->xmit_pending =NULL ; + goto out; } + +if (chan->ops->start_xmit (chan, skb)) + ppp->xmit_pending =NULL ; + +out:spin_unlock (&pch->downl);return ; }
@@ -1981,6 +1998,8 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb)return 0 ;/* can't take now, leave it in xmit_pending */ /* Do protocol field compression */ +if (skb_linearize (skb)) + goto err_linearize; p = skb->data; len = skb->len;if (*p ==0 && mp_protocol_compress) {
@@ -2139,6 +2158,7 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb) noskb:spin_unlock (&pch->downl); + err_linearize:if (ppp->debug &1 )netdev_err (ppp->dev,"PPP: no memory (fragment)\n" ); ++ppp->dev->stats.tx_errors;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 160/609 ppp: annotate data races in ppp_generic
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 543adf072165aaf2e3b635c0476204f9658ed3bf ]
Several fields in struct ppp can be read or updated concurrently from multiple CPUs without synchronization, causing data races:
1. ppp->mru is read concurrently in ppp_receive_nonmp_frame() while being updated via PPPIOCSMRU ioctl. Protect ppp->mru updates in PPPIOCSMRU with ppp_recv_lock(ppp).
2. PPPIOCGFLAGS reads ppp->flags, ppp->xstate, and ppp->rstate unlocked. Wrap the read in ppp_lock(ppp) to get a consistent snapshot.
3. ppp->debug is updated via PPPIOCSDEBUG and read concurrently on fast paths. Annotate reads with READ_ONCE() and writes with WRITE_ONCE().
4. ppp->last_xmit and ppp->last_recv are updated on TX/RX data paths and read via PPPIOCGIDLE32 / PPPIOCGIDLE64 ioctls. Annotate with WRITE_ONCE() / READ_ONCE() and use max() to handle jiffies subtraction.
5. ppp->npmode[] is updated via PPPIOCSNPMODE and read on TX/RX paths. Annotate with WRITE_ONCE() / READ_ONCE().
--- drivers/net/ppp/ppp_generic.c | 50 ++++++++++++++++++++--------------- 1 file changed, 28 insertions(+), 22 deletions(-)
drivers/net/ppp/ppp_generic.c +28 -22
@@ -811,7 +811,9 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)case PPPIOCSMRU :if (get_user (val, p))break ; +ppp_recv_lock (ppp); ppp->mru = val; +ppp_recv_unlock (ppp); err =0 ;break ;
@@ -832,7 +834,9 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)break ;case PPPIOCGFLAGS : +ppp_lock (ppp); val = ppp->flags | ppp->xstate | ppp->rstate; +ppp_unlock (ppp);if (put_user (val, p))break ; err =0 ;
@@ -856,7 +860,7 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)case PPPIOCSDEBUG :if (get_user (val, p))break ; - ppp->debug = val; +WRITE_ONCE (ppp->debug, val); err =0 ;break ;
@@ -867,16 +871,16 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)break ;case PPPIOCGIDLE32 : - idle32.xmit_idle = (jiffies - ppp->last_xmit) /HZ ; - idle32.recv_idle = (jiffies - ppp->last_recv) /HZ ; -if (copy_to_user (argp, &idle32,sizeof (idle32))) + idle32.xmit_idle =max (0L , (long )(jiffies -READ_ONCE (ppp->last_xmit))) /HZ ; + idle32.recv_idle =max (0L , (long )(jiffies -READ_ONCE (ppp->last_recv))) /HZ ; +if (copy_to_user (argp, &idle32,sizeof (idle32)))break ; err =0 ;break ;case PPPIOCGIDLE64 : - idle64.xmit_idle = (jiffies - ppp->last_xmit) /HZ ; - idle64.recv_idle = (jiffies - ppp->last_recv) /HZ ; + idle64.xmit_idle =max (0L , (long )(jiffies -READ_ONCE (ppp->last_xmit))) /HZ ; + idle64.recv_idle =max (0L , (long )(jiffies -READ_ONCE (ppp->last_recv))) /HZ ;if (copy_to_user (argp, &idle64,sizeof (idle64)))break ; err =0 ;
@@ -917,7 +921,7 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)if (copy_to_user (argp, &npi,sizeof (npi)))break ; }else { - ppp->npmode[i] = npi.mode; +WRITE_ONCE (ppp->npmode[i], npi.mode);/* we may be able to transmit more packets now (??) */ netif_wake_queue (ppp->dev); }
@@ -1454,7 +1458,7 @@ ppp_start_xmit(struct sk_buff *skb, struct net_device *dev) goto outf;/* Drop, accept or reject the packet */ -switch (ppp->npmode[npi]) { +switch (READ_ONCE (ppp->npmode[npi])) {case NPMODE_PASS :break ;case NPMODE_QUEUE :
@@ -1769,7 +1773,7 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb) *(__be16 *)skb_push (skb,2 ) =htons (PPP_FILTER_OUTBOUND_TAG );if (ppp->pass_filter &&bpf_prog_run (ppp->pass_filter, skb) ==0 ) { -if (ppp->debug &1 ) +if (READ_ONCE (ppp->debug) &1 )netdev_printk (KERN_DEBUG , ppp->dev,"PPP: outbound frame " "not passed\n" );
@@ -1779,11 +1783,11 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)/* if this packet passes the active filter, record the time */ if (!(ppp->active_filter &&bpf_prog_run (ppp->active_filter, skb) ==0 )) - ppp->last_xmit = jiffies; +WRITE_ONCE (ppp->last_xmit, jiffies);skb_pull (skb,2 );#else /* for data packets, record the time */ - ppp->last_xmit = jiffies; +WRITE_ONCE (ppp->last_xmit, jiffies);#endif /* CONFIG_PPP_FILTER */ }
@@ -2159,7 +2163,7 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb) noskb:spin_unlock (&pch->downl); err_linearize: -if (ppp->debug &1 ) +if (READ_ONCE (ppp->debug) &1 )netdev_err (ppp->dev,"PPP: no memory (fragment)\n" ); ++ppp->dev->stats.tx_errors; ++ppp->nxseq;
@@ -2505,7 +2509,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb) *(__be16 *)skb_push (skb,2 ) =htons (PPP_FILTER_INBOUND_TAG );if (ppp->pass_filter &&bpf_prog_run (ppp->pass_filter, skb) ==0 ) { -if (ppp->debug &1 ) +if (READ_ONCE (ppp->debug) &1 )netdev_printk (KERN_DEBUG , ppp->dev,"PPP: inbound frame " "not passed\n" );
@@ -2514,14 +2518,14 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb) }if (!(ppp->active_filter &&bpf_prog_run (ppp->active_filter, skb) ==0 )) - ppp->last_recv = jiffies; +WRITE_ONCE (ppp->last_recv, jiffies);__skb_pull (skb,2 ); } else#endif /* CONFIG_PPP_FILTER */ - ppp->last_recv = jiffies; +WRITE_ONCE (ppp->last_recv, jiffies);if ((ppp->dev->flags &IFF_UP ) ==0 || - ppp->npmode[npi] !=NPMODE_PASS ) { +READ_ONCE (ppp->npmode[npi]) !=NPMODE_PASS ) {kfree_skb (skb); }else {/* chop off protocol */
@@ -2774,7 +2778,7 @@ ppp_mp_reconstruct(struct ppp *ppp) seq =seq_before (minseq,PPP_MP_CB (p)->sequence)? minseq +1 :PPP_MP_CB (p)->sequence; -if (ppp->debug &1 ) +if (READ_ONCE (ppp->debug) &1 )netdev_printk (KERN_DEBUG , ppp->dev,"lost frag %u..%u\n" , oldseq, seq-1 );
@@ -2823,7 +2827,7 @@ ppp_mp_reconstruct(struct ppp *ppp)struct sk_buff *tmp2; skb_queue_reverse_walk_from_safe(list, p, tmp2) { -if (ppp->debug &1 ) +if (READ_ONCE (ppp->debug) &1 )netdev_printk (KERN_DEBUG , ppp->dev,"discarding frag %u\n" ,PPP_MP_CB (p)->sequence);
@@ -2845,7 +2849,7 @@ ppp_mp_reconstruct(struct ppp *ppp) skb_queue_walk_safe(list, p, tmp) {if (p == head)break ; -if (ppp->debug &1 ) +if (READ_ONCE (ppp->debug) &1 )netdev_printk (KERN_DEBUG , ppp->dev,"discarding frag %u\n" ,PPP_MP_CB (p)->sequence);
@@ -2853,7 +2857,7 @@ ppp_mp_reconstruct(struct ppp *ppp)kfree_skb (p); } -if (ppp->debug &1 ) +if (READ_ONCE (ppp->debug) &1 ) netdev_printk(KERN_DEBUG, ppp->dev, " missed pkts %u..%u\n", ppp->nextseq,
@@ -3163,7 +3167,8 @@ ppp_ccp_peek(struct ppp *ppp, struct sk_buff *skb, int inbound)if (!ppp->rc_state)break ;if (ppp->rcomp->decomp_init (ppp->rc_state, dp, len, - ppp->file.index,0 , ppp->mru, ppp->debug)) { + ppp->file.index,0 , ppp->mru, +READ_ONCE (ppp->debug))) { ppp->rstate |=SC_DECOMP_RUN ; ppp->rstate &= ~(SC_DC_ERROR |SC_DC_FERROR ); }
@@ -3172,7 +3177,8 @@ ppp_ccp_peek(struct ppp *ppp, struct sk_buff *skb, int inbound)if (!ppp->xc_state)break ;if (ppp->xcomp->comp_init (ppp->xc_state, dp, len, - ppp->file.index,0 , ppp->debug)) + ppp->file.index,0 , +READ_ONCE (ppp->debug))) ppp->xstate |=SC_COMP_RUN ; }break ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 161/609 hinic: remove unused ethtool RSS user configuration buffers
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chenguang Zhao <[email protected]>
[ Upstream commit fe0c002928c6749b7f4a726f6f600f6dd70280ea ]
rss_indir_user and rss_hkey_user are allocated and filled in __set_rss_rxfh() when the user configures RSS via ethtool, but nothing ever reads them. hinic_get_rxfh() fetches the state from the device, and the hardware is programmed from the original indir/key arguments. These buffers only leaked on driver unload.
Drop the unused allocations, memcpys, and struct fields.
--- drivers/net/ethernet/huawei/hinic/hinic_dev.h | 2 -- .../net/ethernet/huawei/hinic/hinic_ethtool.c | 21 ------------------- 2 files changed, 23 deletions(-)
drivers/net/ethernet/huawei/hinic/hinic_dev.h +0 -2
@@ -100,8 +100,6 @@ struct hinic_dev {u16 num_rss;u16 rss_limit;struct hinic_rss_type rss_type; -u8 *rss_hkey_user; -s32 *rss_indir_user;struct hinic_intr_coal_info *rx_intr_coalesce;struct hinic_intr_coal_info *tx_intr_coalesce;struct hinic_sriov_info sriov_info;
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c +0 -21
@@ -1061,17 +1061,6 @@ static int __set_rss_rxfh(struct net_device *netdev,int err;if (indir) { -if (!nic_dev->rss_indir_user) { - nic_dev->rss_indir_user = -kzalloc (sizeof (u32) *HINIC_RSS_INDIR_SIZE , -GFP_KERNEL ); -if (!nic_dev->rss_indir_user) -return -ENOMEM ; - } - -memcpy (nic_dev->rss_indir_user, indir, -sizeof (u32) *HINIC_RSS_INDIR_SIZE ); - err =hinic_rss_set_indir_tbl (nic_dev, nic_dev->rss_tmpl_idx, indir);if (err)
@@ -1079,16 +1068,6 @@ static int __set_rss_rxfh(struct net_device *netdev, }if (key) { -if (!nic_dev->rss_hkey_user) { - nic_dev->rss_hkey_user = -kzalloc (HINIC_RSS_KEY_SIZE *2 ,GFP_KERNEL ); - -if (!nic_dev->rss_hkey_user) -return -ENOMEM ; - } - -memcpy (nic_dev->rss_hkey_user, key,HINIC_RSS_KEY_SIZE ); - err =hinic_rss_set_template_tbl (nic_dev, nic_dev->rss_tmpl_idx, key);if (err)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 162/609 net: qrtr: restrict socket creation to the initial network namespace
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aldo Ariel Panzardo <[email protected]>
[ Upstream commit 3b536db8fb32da9e9c62f2bb45e2e319331f0426 ]
QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in.
As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide.
QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).
--- net/qrtr/af_qrtr.c | 8 ++++++++ 1 file changed, 8 insertions(+)
net/qrtr/af_qrtr.c +8 -0
@@ -1257,6 +1257,14 @@ static int qrtr_create(struct net *net, struct socket *sock,if (sock->type !=SOCK_DGRAM )return -EPROTOTYPE ; +/* QRTR keeps its port and node state in module-global variables that +* are not partitioned per network namespace, and the in-kernel name +* service only operates in init_net. Confine the family to init_net so +* a socket in another namespace cannot reach the global control plane. +*/ +if (!net_eq (net, &init_net)) +return -EAFNOSUPPORT ; + sk =sk_alloc (net,AF_QIPCRTR ,GFP_KERNEL , &qrtr_proto, kern);if (!sk)return -ENOMEM ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 163/609 net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yael Chemla <[email protected]>
[ Upstream commit d12956d083eb70f2c6d72711aebaf8c2ce21e170 ]
esw_egress_acl_vlan_create() hardcodes num_dest=0 in its mlx5_add_flow_rules() call. When invoked from the non-bond path fwd_dest is NULL and num_dest=0 is correct. When invoked from esw_acl_egress_ofld_rules_create() during a bond event, fwd_dest is non-NULL and flow_act.action carries MLX5_FLOW_CONTEXT_ACTION_FWD_DEST, but _mlx5_add_flow_rules() rejects a non-NULL dest pointer paired with dest_num<=0 and returns -EINVAL. The error propagates as "configure slave vport egress fwd, err(-22)". The passive vport's egress ACL table ends up with its flow groups allocated but no FTEs, so prio-tagged packets are not popped and bond failover is broken on prio_tag_required devices.
Fix by passing fwd_dest ? 1 : 0 as num_dest to match the actual number of destinations supplied.
--- drivers/net/ethernet/mellanox/mlx5/core/esw/acl/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/helper.c +1 -1
@@ -70,7 +70,7 @@ int esw_egress_acl_vlan_create(struct mlx5_eswitch *esw, flow_act.action = flow_action; vport->egress.allowed_vlan =mlx5_add_flow_rules (vport->egress.acl, spec, - &flow_act, fwd_dest,0 ); + &flow_act, fwd_dest, fwd_dest ?1 :0 );if (IS_ERR (vport->egress.allowed_vlan)) { err =PTR_ERR (vport->egress.allowed_vlan); esw_warn(esw->dev,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 164/609 net/mlx5e: Report zero bandwidth for non-ETS traffic classes
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexei Lazar <[email protected]>
[ Upstream commit ffb1873b2df11945b8c395e859169248675c91c5 ]
The IEEE 802.1Qaz standard defines that bandwidth allocation percentages only apply to Enhanced Transmission Selection (ETS) traffic classes. For STRICT and VENDOR transmission selection algorithms, bandwidth percentage values are not applicable.
Currently for non-ETS 100 bandwidth is being reported for all traffic classes in the get operation due to hardware limitation, regardless of their TSA type.
Fix this by reporting 0 for non-ETS traffic classes.
--- drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c +7 -0
@@ -158,6 +158,13 @@ static int mlx5e_dcbnl_ieee_getets(struct net_device *netdev, }memcpy (ets->tc_tsa, priv->dcbx.tc_tsa,sizeof (ets->tc_tsa)); +/* Report 0 for non ETS TSA */ +for (i =0 ; i < ets->ets_cap; i++) { +if (ets->tc_tx_bw[i] ==MLX5E_MAX_BW_ALLOC && + priv->dcbx.tc_tsa[i] !=IEEE_8021QAZ_TSA_ETS ) + ets->tc_tx_bw[i] =0 ; + } +return err; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 165/609 net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexei Lazar <[email protected]>
[ Upstream commit 9173e1d3c7c7d49a71eee813091f9e834ec7cee5 ]
Credit Based (CB) TSA is not supported by the mlx5 driver, so reject any configurations that specify it.
--- drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c +8 -0
@@ -309,6 +309,14 @@ static int mlx5e_dbcnl_validate_ets(struct net_device *netdev, } } +for (i =0 ; i <IEEE_8021QAZ_MAX_TCS ; i++) { +if (ets->tc_tsa[i] ==IEEE_8021QAZ_TSA_CB_SHAPER ) { +netdev_err (netdev, +"Failed to validate ETS: CB Shaper is not supported\n" ); +return -EOPNOTSUPP ; + } + } +/* Validate Bandwidth Sum */ for (i =0 ; i <IEEE_8021QAZ_MAX_TCS ; i++) {if (ets->tc_tsa[i] ==IEEE_8021QAZ_TSA_ETS ) {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 166/609 net: ipv6: fix dif and sdif mismatch in raw6_icmp_error
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li RongQing <[email protected]>
[ Upstream commit 440e274da4d1b93c7df2cb0ce893c3009dd4db55 ]
In raw6_icmp_error(), raw_v6_match() is called with inet6_iif(skb) passed to both the 'dif' and 'sdif' arguments. This is a copy-paste or typo error, as the last argument should represent the secondary interface index (sdif).
This mismatch breaks ICMPv6 error handling for IPv6 raw sockets in VRF (Virtual Routing and Forwarding) environments. When a raw socket is bound to a VRF master device, raw_v6_match() fails to find a match because it is not given the correct sdif value, causing the socket to miss relevant ICMPv6 error notifications.
Fix this by properly passing inet6_sdif(skb) as the last argument to raw_v6_match().
--- net/ipv6/raw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/raw.c +1 -1
@@ -342,7 +342,7 @@ void raw6_icmp_error(struct sk_buff *skb, int nexthdr,const struct ipv6hdr *ip6h = (const struct ipv6hdr *)skb->data;if (!raw_v6_match (net, sk, nexthdr, &ip6h->saddr, &ip6h->daddr, -inet6_iif (skb),inet6_iif (skb))) +inet6_iif (skb),inet6_sdif (skb)))continue ;rawv6_err (sk, skb,NULL , type, code, inner_offset, info); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 167/609 bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chengfeng Ye <[email protected]>
[ Upstream commit 2d66a033864e27ab8d5e44cb36f31d9d2413bee4 ]
tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork.
This comparison is unsafe when two threads send on the same socket:
Thread A Thread B
msg_tx = psock->cork
sk_msg_alloc() fails sk_stream_wait_memory()
releases the socket lock acquires the socket lock
completes the cork psock->cork = NULL frees the cork
reacquires the socket lock
msg_tx != psock->cork
sk_msg_free(msg_tx)
The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported:
BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0
msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.
--- net/ipv4/tcp_bpf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/tcp_bpf.c +1 -1
@@ -566,7 +566,7 @@ static int tcp_bpf_sendmsg(struct sock *sk, struct msghdr *msg, size_t size) wait_for_memory: err =sk_stream_wait_memory (sk, &timeo);if (err) { -if (msg_tx && msg_tx != psock->cork) +if (msg_tx == &tmp)sk_msg_free (sk, msg_tx); goto out_err; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 168/609 drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Shtylyov <[email protected]>
commit 46c31e1604d121221167cb09380de8c7d53290b9 upstream.
The result of cdn_dp_reg_write() is checked everywhere (with the error being logged by the callers) except one place in cdn_dp_config_video(). Add the missing result check, bailing out early on error...
Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.
--- drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/rockchip/cdn-dp-reg.c +2 -0
@@ -683,6 +683,8 @@ int cdn_dp_config_video(struct cdn_dp_de val =div_u64 (8 * (symbol +1 ), bit_per_pix) - val; val +=2 ; ret =cdn_dp_reg_write (dp,DP_VC_TABLE (15 ), val); +if (ret) + goto err_config_video;switch (video->color_depth) {case 6 :
Greg Kroah-Hartman
maintainerPATCH 169/609 drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ashutosh Desai <[email protected]>
commit 1a8f537f5a1eeac941f262fe73078d6b08ba83c0 upstream.
drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does:
memcpy(bytes, &raw->msg[idx], num_bytes);
without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[].
drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced).
Fix both functions by using a single combined check
(idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed.
--- drivers/gpu/drm/display/drm_dp_mst_topology.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/display/drm_dp_mst_topology.c +4 -2
@@ -861,7 +861,7 @@ static bool drm_dp_sideband_parse_remote goto fail_len; repmsg->u.remote_dpcd_read_ack.num_bytes = raw->msg[idx]; idx++; -if (idx > raw->curlen) +if (idx + repmsg->u.remote_dpcd_read_ack.num_bytes > raw->curlen) goto fail_len;memcpy (repmsg->u.remote_dpcd_read_ack.bytes, &raw->msg[idx], repmsg->u.remote_dpcd_read_ack.num_bytes);
@@ -897,7 +897,9 @@ static bool drm_dp_sideband_parse_remote goto fail_len; repmsg->u.remote_i2c_read_ack.num_bytes = raw->msg[idx]; idx++; -/* TODO check */ +if (idx + repmsg->u.remote_i2c_read_ack.num_bytes > raw->curlen) + goto fail_len; +memcpy (repmsg->u.remote_i2c_read_ack.bytes, &raw->msg[idx], repmsg->u.remote_i2c_read_ack.num_bytes);return true; fail_len:
Greg Kroah-Hartman
maintainerPATCH 170/609 drm/dp/mst: fix buffer overflows in sideband chunk accumulation
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ashutosh Desai <[email protected]>
commit 55bd5e685bda455b9b50c835f8c8442d52a344a3 upstream.
drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data:
1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds.
2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[].
3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields.
All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.
--- drivers/gpu/drm/display/drm_dp_mst_topology.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/gpu/drm/display/drm_dp_mst_topology.c +9 -0
@@ -779,6 +779,12 @@ static bool drm_dp_sideband_append_paylo {u8 crc4; +/* curchunk_len must be >= 1 (min 1 CRC byte) and fit in chunk[] */ +if (!msg->curchunk_len || + msg->curchunk_len >ARRAY_SIZE (msg->chunk) || + msg->curchunk_idx + replybuflen >ARRAY_SIZE (msg->chunk)) +return false; +memcpy (&msg->chunk[msg->curchunk_idx], replybuf, replybuflen); msg->curchunk_idx += replybuflen;
@@ -789,6 +795,9 @@ static bool drm_dp_sideband_append_payloprint_hex_dump (KERN_DEBUG ,"wrong crc" ,DUMP_PREFIX_NONE ,16 ,1 , msg->chunk, msg->curchunk_len, false); +/* Guard against accumulated msg[] overflow */ +if (msg->curlen + msg->curchunk_len -1 >ARRAY_SIZE (msg->msg)) +return false;/* copy chunk into bigger msg */ memcpy (&msg->msg[msg->curlen], msg->chunk, msg->curchunk_len -1 ); msg->curlen += msg->curchunk_len -1 ;
Greg Kroah-Hartman
maintainerPATCH 171/609 drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ashutosh Desai <[email protected]>
commit 6b89ba3dba2f583626fb693e47e951ffb8bf591f upstream.
Three sideband reply parsers read 16-bit fields as:
val = (raw->msg[idx] << 8) | (raw->msg[idx+1]);
and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen).
Affected functions:
- drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields
- drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field
- drm_dp_sideband_parse_query_payload_ack() allocated_pbn field
Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed.
--- drivers/gpu/drm/display/drm_dp_mst_topology.c | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-)
drivers/gpu/drm/display/drm_dp_mst_topology.c +4 -13
@@ -924,16 +924,13 @@ static bool drm_dp_sideband_parse_enum_p repmsg->u.path_resources.port_number = (raw->msg[idx] >>4 ) &0xf ; repmsg->u.path_resources.fec_capable = raw->msg[idx] &0x1 ; idx++; -if (idx > raw->curlen) +if (idx +2 > raw->curlen) goto fail_len; repmsg->u.path_resources.full_payload_bw_number = (raw->msg[idx] <<8 ) | (raw->msg[idx+1 ]); idx +=2 ; -if (idx > raw->curlen) +if (idx +2 > raw->curlen) goto fail_len; repmsg->u.path_resources.avail_payload_bw_number = (raw->msg[idx] <<8 ) | (raw->msg[idx+1 ]); - idx +=2 ; -if (idx > raw->curlen) - goto fail_len;return true; fail_len:DRM_DEBUG_KMS ("enum resource parse length fail %d %d\n" , idx, raw->curlen);
@@ -951,12 +948,9 @@ static bool drm_dp_sideband_parse_alloca goto fail_len; repmsg->u.allocate_payload.vcpi = raw->msg[idx]; idx++; -if (idx > raw->curlen) +if (idx +2 > raw->curlen) goto fail_len; repmsg->u.allocate_payload.allocated_pbn = (raw->msg[idx] <<8 ) | (raw->msg[idx+1 ]); - idx +=2 ; -if (idx > raw->curlen) - goto fail_len;return true; fail_len:DRM_DEBUG_KMS ("allocate payload parse length fail %d %d\n" , idx, raw->curlen);
@@ -970,12 +964,9 @@ static bool drm_dp_sideband_parse_query_ repmsg->u.query_payload.port_number = (raw->msg[idx] >>4 ) &0xf ; idx++; -if (idx > raw->curlen) +if (idx +2 > raw->curlen) goto fail_len; repmsg->u.query_payload.allocated_pbn = (raw->msg[idx] <<8 ) | (raw->msg[idx +1 ]); - idx +=2 ; -if (idx > raw->curlen) - goto fail_len;return true; fail_len:DRM_DEBUG_KMS ("query payload parse length fail %d %d\n" , idx, raw->curlen);
Greg Kroah-Hartman
maintainerPATCH 172/609 drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Timur Kristóf <[email protected]>
commit ee94a65f192c05c543b4d3ad7137cd696b5c18fc upstream.
The UVD code relies on GTT to GTT moves in order to ensure that its BOs don't cross 256M segments.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +18 -0
@@ -463,6 +463,15 @@ static int amdgpu_bo_move(struct ttm_bufif (new_mem->mem_type ==TTM_PL_TT || new_mem->mem_type ==AMDGPU_PL_PREEMPT ) { +if (old_mem && (old_mem->mem_type ==TTM_PL_TT || + old_mem->mem_type ==AMDGPU_PL_PREEMPT )) { + r =ttm_bo_wait_ctx (bo, ctx); +if (r) +return r; + +amdgpu_ttm_backend_unbind (bo->bdev, bo->ttm); + } + r =amdgpu_ttm_backend_bind (bo->bdev, bo->ttm, new_mem);if (r)return r;
@@ -499,6 +508,15 @@ static int amdgpu_bo_move(struct ttm_bufamdgpu_bo_move_notify (bo, evict, new_mem);ttm_resource_free (bo, &bo->resource);ttm_bo_assign_mem (bo, new_mem); +return 0 ; + } +if ((old_mem->mem_type ==TTM_PL_TT || + old_mem->mem_type ==AMDGPU_PL_PREEMPT ) && + (new_mem->mem_type ==TTM_PL_TT || + new_mem->mem_type ==AMDGPU_PL_PREEMPT )) { +amdgpu_bo_move_notify (bo, evict, new_mem); +ttm_resource_free (bo, &bo->resource); +ttm_bo_assign_mem (bo, new_mem);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 173/609 drm/i915/gem: Add missing nospec on parallel submit slot
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joonas Lahtinen <[email protected]>
commit 914a76a9f08366434bf595700f62026b7a19a9cc upstream.
Add missing Spectre mitigation for userspace controlled parallel submission slot.
Discovered using AI-assisted static analysis confirmed by Intel Product Security.
--- drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/i915/gem/i915_gem_context.c +1 -0
@@ -610,6 +610,7 @@ set_proto_ctx_engines_parallel_submit(streturn -EINVAL ; } + slot =array_index_nospec (slot, set->num_engines);if (set->engines[slot].type !=I915_GEM_ENGINE_TYPE_INVALID ) {drm_dbg (&i915->drm,"Invalid placement[%d], already occupied\n" , slot);
Greg Kroah-Hartman
maintainerPATCH 174/609 drm/nouveau/acr: fix missing nvkm_done() in error path of nvkm_acr_oneinit()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wentao Liang <[email protected]>
commit c3027973f692077a1b66a9fb26d6a7c46c0dc72c upstream.
In nvkm_acr_oneinit(), nvkm_kmap(acr->wpr) is invoked unconditionally at line 309 to obtain a mapping reference. Additionally, when both acr->wpr_fw and acr->wpr_comp are present, a second nvkm_kmap() is called inside the conditional block. Both mappings are expected to be released by nvkm_done(acr->wpr) at line 320 before the function returns successfully.
However, when a mismatch is detected during the loop within the conditional block, the function returns -EINVAL at line 318 without calling nvkm_done(). This results in a leak of the kmap reference(s) acquired earlier.
Fix the issue by invoking nvkm_done(acr->wpr) prior to the early return to ensure proper release of the mapping references.
--- drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c +1 -0
@@ -314,6 +314,7 @@ nvkm_acr_oneinit(struct nvkm_subdev *sub i, us, fw); } } +nvkm_done (acr->wpr);return -EINVAL ; }nvkm_done (acr->wpr);
Greg Kroah-Hartman
maintainerPATCH 175/609 drm/radeon: fix r100_copy_blit for large BOs
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Ondračka <[email protected]>
commit f896e86273dbbebb5eac966b4a201b5c62a02e9a upstream.
r100_copy_blit() copies BOs as 1024-pixel-wide ARGB8888 blits, so one GPU page becomes one blit row. Large copies are split into chunks of at most 8191 rows.
The kernel register header names the packet coordinate dwords SRC_Y_X and DST_Y_X. In the BITBLT_MULTI description in R5xx_Acceleration_v1.5.pdf docs, these correspond to [SRC_X1 | SRC_Y1] and [DST_X1 | DST_Y1], which are signed 13-bit coordinates in the -8192..8191 range. The old code kept SRC/DST_PITCH_OFFSET at the BO base and used SRC_Y_X/DST_Y_X as the chunk address, so large BO moves could exceed that coordinate range.
Compute per-chunk SRC/DST_PITCH_OFFSET bases and emit zero source and destination coordinates. r100_copy_blit() already packs SRC/DST_PITCH_OFFSET as pitch plus base offset, so large chunk addresses belong there rather than in the coordinate fields.
This fixes Prison Architect corruption with 4096x4096 mipped textures after they are evicted to GTT under memory pressure on RV530.
--- drivers/gpu/drm/radeon/r100.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/gpu/drm/radeon/r100.c +9 -4
@@ -905,6 +905,7 @@ struct radeon_fence *r100_copy_blit(stru {struct radeon_ring *ring = &rdev->ring[RADEON_RING_TYPE_GFX_INDEX ];struct radeon_fence *fence; +uint64_t cur_src_offset, cur_dst_offset;uint32_t cur_pages;uint32_t stride_bytes =RADEON_GPU_PAGE_SIZE ;uint32_t pitch;
@@ -933,6 +934,10 @@ struct radeon_fence *r100_copy_blit(stru cur_pages =8191 ; } num_gpu_pages -= cur_pages; + cur_src_offset = src_offset + + (uint64_t )num_gpu_pages *RADEON_GPU_PAGE_SIZE ; + cur_dst_offset = dst_offset + + (uint64_t )num_gpu_pages *RADEON_GPU_PAGE_SIZE ;/* pages are in Y direction - height page width in X direction - width */
@@ -949,13 +954,13 @@ struct radeon_fence *r100_copy_blit(struRADEON_DP_SRC_SOURCE_MEMORY |RADEON_GMC_CLR_CMP_CNTL_DIS | RADEON_GMC_WR_MSK_DIS); -radeon_ring_write (ring, (pitch <<22 ) | (src_offset >>10 )); -radeon_ring_write (ring, (pitch <<22 ) | (dst_offset >>10 )); +radeon_ring_write (ring, (pitch <<22 ) | (cur_src_offset >>10 )); +radeon_ring_write (ring, (pitch <<22 ) | (cur_dst_offset >>10 ));radeon_ring_write (ring, (0x1fff ) | (0x1fff <<16 ));radeon_ring_write (ring,0 );radeon_ring_write (ring, (0x1fff ) | (0x1fff <<16 )); -radeon_ring_write (ring, num_gpu_pages); -radeon_ring_write (ring, num_gpu_pages); +radeon_ring_write (ring,0 ); +radeon_ring_write (ring,0 );radeon_ring_write (ring, cur_pages | (stride_pixels <<16 )); }radeon_ring_write (ring,PACKET0 (RADEON_DSTCACHE_CTLSTAT ,0 ));
Greg Kroah-Hartman
maintainerPATCH 176/609 drm/amdkfd: Check bounds in allocate_event_notification_slot
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Francis <[email protected]>
commit bb52249fbbe948875155ccd45cd8d74bf4ae747b upstream.
The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT
allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value.
Check them.
v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist
--- drivers/gpu/drm/amd/amdkfd/kfd_events.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/amd/amdkfd/kfd_events.c +3 -0
@@ -106,6 +106,9 @@ static int allocate_event_notification_s }if (restore_id) { +if (*restore_id >=KFD_SIGNAL_EVENT_LIMIT ) +return -EINVAL ; + id =idr_alloc (&p->event_idr, ev, *restore_id, *restore_id +1 ,GFP_KERNEL ); }else {
Greg Kroah-Hartman
maintainerPATCH 177/609 drm/virtio: bound EDID block reads to the response buffer
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bryam Vargas <[email protected]>
commit 4e1a53892ba7f8a3e1da6bfc53c83ae7c812dccd upstream.
virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak).
Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.
--- drivers/gpu/drm/virtio/virtgpu_vq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/virtio/virtgpu_vq.c +2 -1
@@ -719,7 +719,8 @@ static int virtio_get_edid_block(void *dstruct virtio_gpu_resp_edid *resp = data;size_t start = block *EDID_LENGTH ; -if (start + len >le32_to_cpu (resp->size)) +if (start + len >le32_to_cpu (resp->size) || + start + len >sizeof (resp->edid))return -EINVAL ;memcpy (buf, resp->edid + start, len);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 178/609 drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit ec42c96c322e5cc48099ab5e67b5cbe236cb1949 upstream.
There's no need to crash the kernel for these cases.
--- drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c +2 -2
@@ -363,7 +363,7 @@ static void sdma_v6_0_ring_emit_fence(stamdgpu_ring_write (ring,SDMA_PKT_COPY_LINEAR_HEADER_OP (SDMA_OP_FENCE ) |SDMA_PKT_FENCE_HEADER_MTYPE (0x3 ));/* Ucached(UC) */ /* zero in first two bits */ -BUG_ON (addr &0x3 ); +WARN_ON (addr &0x3 );amdgpu_ring_write (ring,lower_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (addr));amdgpu_ring_write (ring,lower_32_bits (seq));
@@ -374,7 +374,7 @@ static void sdma_v6_0_ring_emit_fence(stamdgpu_ring_write (ring,SDMA_PKT_COPY_LINEAR_HEADER_OP (SDMA_OP_FENCE ) |SDMA_PKT_FENCE_HEADER_MTYPE (0x3 ));/* zero in first two bits */ -BUG_ON (addr &0x3 ); +WARN_ON (addr &0x3 );amdgpu_ring_write (ring,lower_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (seq));
Greg Kroah-Hartman
maintainerPATCH 179/609 drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit b9dd618a635d39fbb211454b6e8837b2a7f10fb0 upstream.
There's no need to crash the kernel for these cases.
--- drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c +2 -2
@@ -390,7 +390,7 @@ static void sdma_v5_2_ring_emit_fence(stamdgpu_ring_write (ring,SDMA_PKT_HEADER_OP (SDMA_OP_FENCE ) |SDMA_PKT_FENCE_HEADER_MTYPE (0x3 ));/* Ucached(UC) */ /* zero in first two bits */ -BUG_ON (addr &0x3 ); +WARN_ON (addr &0x3 );amdgpu_ring_write (ring,lower_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (addr));amdgpu_ring_write (ring,lower_32_bits (seq));
@@ -401,7 +401,7 @@ static void sdma_v5_2_ring_emit_fence(stamdgpu_ring_write (ring,SDMA_PKT_HEADER_OP (SDMA_OP_FENCE ) |SDMA_PKT_FENCE_HEADER_MTYPE (0x3 ));/* zero in first two bits */ -BUG_ON (addr &0x3 ); +WARN_ON (addr &0x3 );amdgpu_ring_write (ring,lower_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (seq));
Greg Kroah-Hartman
maintainerPATCH 180/609 drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 9e98ed3113943257ad6e5c1e6beddbdb482a70ad upstream.
There's no need to crash the kernel for these cases.
--- drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c +2 -2
@@ -548,7 +548,7 @@ static void sdma_v5_0_ring_emit_fence(stamdgpu_ring_write (ring,SDMA_PKT_HEADER_OP (SDMA_OP_FENCE ) |SDMA_PKT_FENCE_HEADER_MTYPE (0x3 ));/* Ucached(UC) */ /* zero in first two bits */ -BUG_ON (addr &0x3 ); +WARN_ON (addr &0x3 );amdgpu_ring_write (ring,lower_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (addr));amdgpu_ring_write (ring,lower_32_bits (seq));
@@ -559,7 +559,7 @@ static void sdma_v5_0_ring_emit_fence(stamdgpu_ring_write (ring,SDMA_PKT_HEADER_OP (SDMA_OP_FENCE ) |SDMA_PKT_FENCE_HEADER_MTYPE (0x3 ));/* zero in first two bits */ -BUG_ON (addr &0x3 ); +WARN_ON (addr &0x3 );amdgpu_ring_write (ring,lower_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (seq));
Greg Kroah-Hartman
maintainerPATCH 181/609 drm/i915: Return NULL on error in active_instance
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joonas Lahtinen <[email protected]>
commit 1e33f0de5fdcd09e51fdec1e5822448970b6420f upstream.
Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation.
Discovered using AI-assisted static analysis confirmed by Intel Product Security.
--- drivers/gpu/drm/i915/i915_active.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_active.c +6 -1
@@ -319,7 +319,7 @@ active_instance(struct i915_active *ref,*/ node =kmem_cache_alloc (slab_cache,GFP_ATOMIC );if (!node) - goto out; + goto err;__i915_active_fence_init (&node->base,NULL , node_retire); node->ref = ref;
@@ -333,6 +333,11 @@ out:spin_unlock_irq (&ref->tree_lock);return &node->base; + +err: +spin_unlock_irq (&ref->tree_lock); + +return NULL ; } void __i915_active_init(struct i915_active *ref,
Greg Kroah-Hartman
maintainerPATCH 182/609 drm/i915/gem: Do not leak siblings[] on proto context error
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joonas Lahtinen <[email protected]>
commit eed3de2acf6aa5154d49098b026710b646db67ee upstream.
After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that.
Discovered using AI-assisted static analysis confirmed by Intel Product Security.
--- drivers/gpu/drm/i915/gem/i915_gem_context.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-)
drivers/gpu/drm/i915/gem/i915_gem_context.c +14 -8
@@ -768,8 +768,8 @@ static int set_proto_ctx_engines(structstruct intel_engine_cs *engine;if (copy_from_user (&ci, &user->engines[n],sizeof (ci))) { -kfree (set.engines); -return -EFAULT ; + err = -EFAULT ; + goto err; }memset (&set.engines[n],0 ,sizeof (set.engines[n]));
@@ -785,8 +785,8 @@ static int set_proto_ctx_engines(structdrm_dbg (&i915->drm,"Invalid engine[%d]: { class:%d, instance:%d }\n" , n, ci.engine_class, ci.engine_instance); -kfree (set.engines); -return -ENOENT ; + err = -ENOENT ; + goto err; } set.engines[n].type =I915_GEM_ENGINE_TYPE_PHYSICAL ;
@@ -799,15 +799,21 @@ static int set_proto_ctx_engines(struct set_proto_ctx_engines_extensions,ARRAY_SIZE (set_proto_ctx_engines_extensions), &set); -if (err) { -kfree (set.engines); -return err; - } +if (err) + goto err_extensions; pc->num_user_engines = set.num_engines; pc->user_engines = set.engines;return 0 ; + +err_extensions: +for (n =0 ; n < set.num_engines; n++) +kfree (set.engines[n].siblings); +err: +kfree (set.engines); + +return err; } static int set_proto_ctx_sseu(struct drm_i915_file_private *fpriv,
Greg Kroah-Hartman
maintainerPATCH 183/609 drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joonas Lahtinen <[email protected]>
commit 2b56757a9a7456825eb668fde92299e01c5e2721 upstream.
Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that.
Discovered using AI-assisted static analysis confirmed by Intel Product Security.
--- drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/gem/i915_gem_context.c +1 -1
@@ -855,7 +855,7 @@ static int set_proto_ctx_sseu(struct drm pe = &pc->user_engines[idx];/* Only render engine supports RPCS configuration. */ -if (pe->engine->class !=RENDER_CLASS ) +if (!pe->engine || pe->engine->class !=RENDER_CLASS )return -EINVAL ; sseu = &pe->sseu;
Greg Kroah-Hartman
maintainerPATCH 184/609 drm/amdgpu: Fix VFCT bus number matching with soft filter
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit db7e8108809a2245f0a17ba323f027cac0941ffb upstream.
On systems where PCI bus renumbering occurs (e.g. pci=realloc, resource conflicts), the runtime bus number may differ from the BIOS POST bus number recorded in the VFCT table. This causes amdgpu_acpi_vfct_bios() to fail finding the VBIOS even though the correct device entry exists.
Introduce amdgpu_acpi_vfct_match() which treats the bus number as a soft filter: vendor/device/function identity is the hard requirement, while exact bus match is the preferred path. When bus numbers disagree but device identity matches, accept the VFCT entry and log a dev_notice for diagnostics.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 45 +++++++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c +40 -5
@@ -363,6 +363,45 @@ static bool amdgpu_read_disabled_bios(st }#ifdef CONFIG_ACPI +/** +* amdgpu_acpi_vfct_match() - Check if a VFCT entry matches the device +* @adev: AMDGPU device +* @vhdr: VFCT image header to check +* +* VFCT entries contain the PCI bus number as recorded during BIOS POST. +* On systems where the kernel renumbers PCI buses (e.g. pci=realloc or +* resource conflicts), the runtime bus number may differ from the POST +* value. Match by device identity (vendor + device + function) and use +* the bus number as a preference: exact bus match is preferred, but when +* the bus numbers disagree we accept the entry if the device identity +* matches. +* +* Returns: 0 on match, -ENODEV on no match +*/ +static int amdgpu_acpi_vfct_match (struct amdgpu_device *adev, +VFCT_IMAGE_HEADER *vhdr) +{ +/* Vendor and device IDs must always match */ +if (vhdr->VendorID != adev->pdev->vendor || + vhdr->DeviceID != adev->pdev->device) +return -ENODEV ; + +if (vhdr->PCIDevice !=PCI_SLOT (adev->pdev->devfn) || + vhdr->PCIFunction !=PCI_FUNC (adev->pdev->devfn)) +return -ENODEV ; + +/* Exact bus number match - preferred */ +if (vhdr->PCIBus == adev->pdev->bus->number) +return 0 ; + +/* Bus mismatch but device identity matches (PCI renumbering case) */ +dev_notice (adev->dev, +"VFCT bus number mismatch: table %u != runtime %u, matching by device identity (vendor 0x%04x device 0x%04x)\n" , + vhdr->PCIBus, adev->pdev->bus->number, + adev->pdev->vendor, adev->pdev->device); +return 0 ; +} +static bool amdgpu_acpi_vfct_bios (struct amdgpu_device *adev) {struct acpi_table_header *hdr;
@@ -398,11 +437,7 @@ static bool amdgpu_acpi_vfct_bios(struct }if (vhdr->ImageLength && - vhdr->PCIBus == adev->pdev->bus->number && - vhdr->PCIDevice ==PCI_SLOT (adev->pdev->devfn) && - vhdr->PCIFunction ==PCI_FUNC (adev->pdev->devfn) && - vhdr->VendorID == adev->pdev->vendor && - vhdr->DeviceID == adev->pdev->device) { + !amdgpu_acpi_vfct_match (adev, vhdr)) { adev->bios =kmemdup (&vbios->VbiosContent, vhdr->ImageLength,GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 185/609 drm/amd/pm/ci: Dont disable MCLK DPM on Bonaire 0x6658 (R7 260X)
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Timur Kristóf <[email protected]>
commit 85371c5ef502d10add72eab38711e191dccea981 upstream.
The old radeon driver has a documented workaround in ci_dpm.c which claims that Bonaire 0x6658 with old memory controller firmware is unstable with MCLK DPM, so as a precaution I disabled MCLK DPM on this ASIC in amdgpu.
Note that the old MC firmware is not actually used with amdgpu, but in theory it's possible that the VBIOS sets up the ASIC with an old MC firmware that is already running when amdgpu initializes (in which case amdgpu doesn't load its own firmware).
What I expected to happen is that the GPU would simply use its maximum memory clock, and indeed this is what seemed to happen according to amdgpu_pm_info which reads the current MCLK value from the SMU.
However, some users reported a huge perf regression and upon a closer look it seems that the GPU seems to not actually use the highest MCLK value, despite the SMU reporting that it does.
Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X).
Keep MCLK DPM disabled on R9 M380 in the 2015 iMac because that still hangs if we enable it.
--- drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c +2 -5
@@ -106,11 +106,8 @@ int hwmgr_early_init(struct pp_hwmgr *hw hwmgr->od_enabled = false;switch (hwmgr->chip_id) {case CHIP_BONAIRE : -/* R9 M380 in iMac 2015: SMU hangs when enabling MCLK DPM -* R7 260X cards with old MC ucode: MCLK DPM is unstable -*/ -if (adev->pdev->subsystem_vendor ==0x106B || - adev->pdev->device ==0x6658 ) { +/* R9 M380 in iMac 2015: SMU hangs when enabling MCLK DPM */ +if (adev->pdev->subsystem_vendor ==0x106B ) {dev_info (adev->dev,"disabling MCLK DPM on quirky ASIC" ); adev->pm.pp_feature &= ~PP_MCLK_DPM_MASK ; hwmgr->feature_mask &= ~PP_MCLK_DPM_MASK ;
Greg Kroah-Hartman
maintainerPATCH 186/609 drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhu Lingshan <[email protected]>
commit a2f895f3c852063258d62e9f74b081de07ca95df upstream.
amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards.
When the same non-NULL BO pointer is passed in again,
for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start
under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks.
This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +8 -5
@@ -267,10 +267,12 @@ int amdgpu_bo_create_reserved(struct amd goto error_free; } - r =amdgpu_bo_pin (*bo_ptr, domain); -if (r) { -dev_err (adev->dev,"(%d) kernel bo pin failed\n" , r); - goto error_unreserve; +if (free) { + r =amdgpu_bo_pin (*bo_ptr, domain); +if (r) { +dev_err (adev->dev,"(%d) kernel bo pin failed\n" , r); + goto error_unreserve; + } } r =amdgpu_ttm_alloc_gart (&(*bo_ptr)->tbo);
@@ -293,7 +295,8 @@ int amdgpu_bo_create_reserved(struct amdreturn 0 ; error_unpin: -amdgpu_bo_unpin (*bo_ptr); +if (free) +amdgpu_bo_unpin (*bo_ptr); error_unreserve:amdgpu_bo_unreserve (*bo_ptr);
Greg Kroah-Hartman
maintainerPATCH 187/609 drm/vmwgfx: Validate vmw_surface_metadata::array_size
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Forbes <[email protected]>
commit a4f55260f7f7d4dc4d0ee55063dfb0c457b77991 upstream.
This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.
--- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c +17 -5
@@ -98,7 +98,7 @@ static int vmw_gb_surface_unbind(structstatic int vmw_gb_surface_destroy (struct vmw_resource *res);static int vmw_gb_surface_define_internal (struct drm_device *dev, -struct drm_vmw_gb_surface_create_ext_req *req, +const struct drm_vmw_gb_surface_create_ext_req *req,struct drm_vmw_gb_surface_create_rep *rep,struct drm_file *file_priv); static int
@@ -1406,7 +1406,7 @@ int vmw_gb_surface_reference_ext_ioctl(s*/ static int vmw_gb_surface_define_internal (struct drm_device *dev, -struct drm_vmw_gb_surface_create_ext_req *req, +const struct drm_vmw_gb_surface_create_ext_req *req,struct drm_vmw_gb_surface_create_rep *rep,struct drm_file *file_priv) {
@@ -1424,9 +1424,21 @@ vmw_gb_surface_define_internal(struct dr req->base.svga3d_flags);/* array_size must be null for non-GL3 host. */ -if (req->base.array_size >0 && !has_sm4_context (dev_priv)) { -VMW_DEBUG_USER ("SM4 surface not supported.\n" ); -return -EINVAL ; +if (req->base.array_size >0 ) { +if (has_sm5_context (dev_priv)) { +if (req->base.array_size >SVGA3D_SM5_MAX_SURFACE_ARRAYSIZE ) { +VMW_DEBUG_USER ("Invalid Surface Array Size.\n" ); +return -EINVAL ; + } + }else if (has_sm4_context (dev_priv)) { +if (req->base.array_size >SVGA3D_SM4_MAX_SURFACE_ARRAYSIZE ) { +VMW_DEBUG_USER ("Invalid Surface Array Size.\n" ); +return -EINVAL ; + } + }else { +VMW_DEBUG_USER ("SM4+ surface not supported.\n" ); +return -EINVAL ; + } }if (!has_sm4_1_context (dev_priv)) {
Greg Kroah-Hartman
maintainerPATCH 188/609 media: airspy: Return queued buffers on start_streaming() failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Valery Borovsky <[email protected]>
commit 04344d0b4929caa94c0df72f767752aa0935ef5d upstream.
The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak.
airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
--- drivers/media/usb/airspy/airspy.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/media/usb/airspy/airspy.c +5 -3
@@ -521,11 +521,13 @@ static int airspy_start_streaming(structdev_dbg (s->dev,"\n" ); -if (!s->udev) -return -ENODEV ; -mutex_lock (&s->v4l2_lock); +if (!s->udev) { + ret = -ENODEV ; + goto err_clear_bit; + } + s->sequence =0 ;set_bit (POWER_ON , &s->flags);
Greg Kroah-Hartman
maintainerPATCH 189/609 media: aspeed: fix missing of_reserved_mem_device_release() on probe failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Carlier <[email protected]>
commit 253c8ef7d57da0c74db251f385324faaa5ae2257 upstream.
aspeed_video_init() calls of_reserved_mem_device_init() to associate reserved memory regions with the device. When aspeed_video_setup_video() subsequently fails in aspeed_video_probe(), the error path frees the JPEG buffer and unprepares the clocks but does not release the reserved memory association, leaking the rmem_assigned_device entry on the global list.
The normal remove path already calls of_reserved_mem_device_release() correctly; only the probe error path was missing it.
Add the missing of_reserved_mem_device_release() call to the aspeed_video_setup_video() failure cleanup.
--- drivers/media/platform/aspeed/aspeed-video.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/platform/aspeed/aspeed-video.c +1 -0
@@ -1994,6 +1994,7 @@ static int aspeed_video_probe(struct pla rc =aspeed_video_setup_video (video);if (rc) {aspeed_video_free_buf (video, &video->jpeg); +of_reserved_mem_device_release (&pdev->dev);clk_unprepare (video->vclk);clk_unprepare (video->eclk);return rc;
Greg Kroah-Hartman
maintainerPATCH 190/609 media: cec: seco: unregister adapter on IR probe failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Myeonghun Pak <[email protected]>
commit c3a78691be8245e52ced489f268e413f18061ac2 upstream.
If secocec_ir_probe() fails after cec_register_adapter() succeeds, probe returns an error and the driver remove callback is not called. The current unwind path unregisters the notifier and then falls through to cec_delete_adapter(), which violates the CEC adapter lifetime rules after a successful registration.
Add a registered-adapter unwind path that unregisters the notifier and the adapter instead.
--- drivers/media/cec/platform/seco/seco-cec.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/media/cec/platform/seco/seco-cec.c +5 -1
@@ -649,7 +649,7 @@ static int secocec_probe(struct platform ret =secocec_ir_probe (secocec);if (ret) - goto err_notifier; + goto err_unregister_adapter;platform_set_drvdata (pdev, secocec);
@@ -657,6 +657,10 @@ static int secocec_probe(struct platformreturn ret; +err_unregister_adapter: +cec_notifier_cec_adap_unregister (secocec->notifier, secocec->cec_adap); +cec_unregister_adapter (secocec->cec_adap); + goto err; err_notifier:cec_notifier_cec_adap_unregister (secocec->notifier, secocec->cec_adap); err_delete_adapter:
Greg Kroah-Hartman
maintainerPATCH 191/609 media: cedrus: clean up media device on probe failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Myeonghun Pak <[email protected]>
commit 2c869b6969f3061cbbdab587f4c0a88bd7fc3cc9 upstream.
cedrus_probe() initializes the media device before registering the video device, the media controller, and the media device. If any of those later steps fails, probe returns without calling media_device_cleanup(), so the media device internals initialized by media_device_init() are left behind.
Add a media-device cleanup label to the probe unwind path and route video registration failures through it as well.
--- drivers/staging/media/sunxi/cedrus/cedrus.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/staging/media/sunxi/cedrus/cedrus.c +3 -2
@@ -503,7 +503,7 @@ static int cedrus_probe(struct platform_ ret =video_register_device (vfd,VFL_TYPE_VIDEO ,0 );if (ret) {v4l2_err (&dev->v4l2_dev,"Failed to register video device\n" ); - goto err_m2m; + goto err_media; } v4l2_info(&dev->v4l2_dev,
@@ -529,7 +529,8 @@ err_m2m_mc:v4l2_m2m_unregister_media_controller (dev->m2m_dev); err_video:video_unregister_device (&dev->vfd); -err_m2m: +err_media: +media_device_cleanup (&dev->mdev);v4l2_m2m_release (dev->m2m_dev); err_v4l2:v4l2_device_unregister (&dev->v4l2_dev);
Greg Kroah-Hartman
maintainerPATCH 192/609 media: cedrus: Fix missing cleanup in error path
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Samuel Holland <[email protected]>
commit d99732334aaf33b9f93926b70b6a11c2cef3de39 upstream.
According to the documentation struct v4l2_fh has to be cleaned up with v4l2_fh_exit() before being freed. [1]
Currently there is no actual bug here, when v4l2_fh_exit() isn't called. v4l2_fh_exit() in this case only destroys internal mutex. But it may change in the future, when v4l2_fh_init/v4l2_fh_exit will be enhanced.
1. https://docs.kernel.org/driver-api/media/v4l2-fh.html
--- drivers/staging/media/sunxi/cedrus/cedrus.c | 1 + 1 file changed, 1 insertion(+)
drivers/staging/media/sunxi/cedrus/cedrus.c +1 -0
@@ -381,6 +381,7 @@ static int cedrus_open(struct file *file err_ctrls:v4l2_ctrl_handler_free (&ctx->hdl); err_free: +v4l2_fh_exit (&ctx->fh);kfree (ctx);mutex_unlock (&dev->dev_mutex);
Greg Kroah-Hartman
maintainerPATCH 193/609 media: cedrus: skip invalid H.264 reference list entries
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pengpeng Hou <[email protected]>
commit 10358ea986c3c85516d1c8206486464f79d36e76 upstream.
Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list().
Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array.
This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.
--- drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/staging/media/sunxi/cedrus/cedrus_h264.c +3 -0
@@ -190,6 +190,9 @@ static void _cedrus_write_ref_list(strucu8 dpb_idx; dpb_idx = ref_list[i].index; +if (dpb_idx >=V4L2_H264_NUM_DPB_ENTRIES ) +continue ; + dpb = &decode->dpb[dpb_idx];if (!(dpb->flags &V4L2_H264_DPB_ENTRY_FLAG_ACTIVE ))
Greg Kroah-Hartman
maintainerPATCH 194/609 media: cx231xx: fix devres lifetime
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 7d6358ab02866e5b7ed8d3a00805297617bbb0ec upstream.
USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes).
Fix the driver state lifetime so that it is released on driver unbind.
--- drivers/media/usb/cx231xx/cx231xx-cards.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
drivers/media/usb/cx231xx/cx231xx-cards.c +11 -5
@@ -1577,7 +1577,8 @@ static int cx231xx_init_v4l2(struct cx23 dev->video_mode.end_point_addr, dev->video_mode.num_alt); - dev->video_mode.alt_max_pkt_size =devm_kmalloc_array (&udev->dev,32 , dev->video_mode.num_alt,GFP_KERNEL ); + dev->video_mode.alt_max_pkt_size =devm_kmalloc_array (&interface->dev,32 , + dev->video_mode.num_alt,GFP_KERNEL );if (dev->video_mode.alt_max_pkt_size ==NULL )return -ENOMEM ;
@@ -1618,7 +1619,8 @@ static int cx231xx_init_v4l2(struct cx23 dev->vbi_mode.num_alt);/* compute alternate max packet sizes for vbi */ - dev->vbi_mode.alt_max_pkt_size =devm_kmalloc_array (&udev->dev,32 , dev->vbi_mode.num_alt,GFP_KERNEL ); + dev->vbi_mode.alt_max_pkt_size =devm_kmalloc_array (&interface->dev,32 , + dev->vbi_mode.num_alt,GFP_KERNEL );if (dev->vbi_mode.alt_max_pkt_size ==NULL )return -ENOMEM ;
@@ -1660,7 +1662,9 @@ static int cx231xx_init_v4l2(struct cx23"sliced CC EndPoint Addr 0x%x, Alternate settings: %i\n" , dev->sliced_cc_mode.end_point_addr, dev->sliced_cc_mode.num_alt); - dev->sliced_cc_mode.alt_max_pkt_size =devm_kmalloc_array (&udev->dev,32 , dev->sliced_cc_mode.num_alt,GFP_KERNEL ); + dev->sliced_cc_mode.alt_max_pkt_size =devm_kmalloc_array (&interface->dev,32 , + dev->sliced_cc_mode.num_alt, +GFP_KERNEL );if (dev->sliced_cc_mode.alt_max_pkt_size ==NULL )return -ENOMEM ;
@@ -1724,7 +1728,7 @@ static int cx231xx_usb_probe(struct usb_ udev =usb_get_dev (interface_to_usbdev (interface));/* allocate memory for our device state and initialize it */ - dev =devm_kzalloc (&udev->dev,sizeof (*dev),GFP_KERNEL ); + dev =devm_kzalloc (&interface->dev,sizeof (*dev),GFP_KERNEL );if (dev ==NULL ) { retval = -ENOMEM ; goto err_if;
@@ -1854,7 +1858,9 @@ static int cx231xx_usb_probe(struct usb_ dev->ts1_mode.end_point_addr, dev->ts1_mode.num_alt); - dev->ts1_mode.alt_max_pkt_size =devm_kmalloc_array (&udev->dev,32 , dev->ts1_mode.num_alt,GFP_KERNEL ); + dev->ts1_mode.alt_max_pkt_size =devm_kmalloc_array (&interface->dev,32 , + dev->ts1_mode.num_alt, +GFP_KERNEL );if (dev->ts1_mode.alt_max_pkt_size ==NULL ) { retval = -ENOMEM ; goto err_video_alt;
Greg Kroah-Hartman
maintainerPATCH 195/609 media: cx23885: add ioremap return check and cleanup
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wang Jun <[email protected]>
commit a0701e387b46e2481c05b47f1235b954bfc2af3e upstream.
Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup().
If ioremap for BAR0 fails, release the already allocated PCI memory region,
decrement the device count, and return -ENODEV.
This prevents a potential null pointer dereference and ensures proper cleanup
on memory mapping failure.
--- drivers/media/pci/cx23885/cx23885-core.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/media/pci/cx23885/cx23885-core.c +12 -2
@@ -990,8 +990,12 @@ static int cx23885_dev_setup(struct cx23 }/* PCIe stuff */ - dev->lmmio =ioremap (pci_resource_start (dev->pci,0 ), -pci_resource_len (dev->pci,0 )); + dev->lmmio =pci_ioremap_bar (dev->pci,0 ); +if (!dev->lmmio) { +dev_err (&dev->pci->dev,"CORE %s: can't ioremap MMIO memory\n" , + dev->name); + goto err_release_region; + } dev->bmmio = (u8 __iomem *)dev->lmmio;
@@ -1096,6 +1100,12 @@ static int cx23885_dev_setup(struct cx23 }return 0 ; + +err_release_region: +release_mem_region (pci_resource_start (dev->pci,0 ), +pci_resource_len (dev->pci,0 )); + cx23885_devcount--; +return -ENODEV ; }static void cx23885_dev_unregister (struct cx23885_dev *dev)
Greg Kroah-Hartman
maintainerPATCH 196/609 media: marvell-cam: fix missing pci_disable_device() on remove
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guangshuo Li <[email protected]>
commit 033ff0420e4c9c240ae5523fff39770298efa964 upstream.
During manual code audit, we found that cafe_pci_probe() enables the PCI device with pci_enable_device(), and its probe error path properly calls pci_disable_device() on failure.
However, cafe_pci_remove() tears down the controller and frees the driver data without disabling the PCI device, leaving the remove path inconsistent with probe cleanup.
Add the missing pci_disable_device() call to cafe_pci_remove().
--- drivers/media/platform/marvell/cafe-driver.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/platform/marvell/cafe-driver.c +1 -0
@@ -601,6 +601,7 @@ static void cafe_pci_remove(struct pci_dreturn ; }cafe_shutdown (cam); +pci_disable_device (pdev);kfree (cam); }
Greg Kroah-Hartman
maintainerPATCH 197/609 media: meson: vdec: Fix memory leak in error path of vdec_open
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anand Moon <[email protected]>
commit 940f161f734b25f175a95d2684c2021f6323693a upstream.
The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak.
Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device.
This was identified via kmemleak:
unreferenced object 0xffff0000205d6878 (size 8):
comm "v4l_id", pid 5289, jiffies 4294938580
hex dump (first 8 bytes):
40 d2 49 18 00 00 ff ff @.I.....
backtrace (crc d3204599):
kmemleak_alloc+0xc8/0xf0
__kvmalloc_node_noprof+0x60c/0x850
v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev]
vdec_open+0x1f4/0x788 [meson_vdec]
v4l2_open+0x144/0x460 [videodev]
chrdev_open+0x1ac/0x500
do_dentry_open+0x3f0/0xfe8
vfs_open+0x68/0x320
do_open+0x2d8/0x9a8
path_openat+0x1d0/0x4f0
do_filp_open+0x190/0x380
do_sys_openat2+0xf8/0x1b0
__arm64_sys_openat+0x13c/0x1e8
invoke_syscall+0xdc/0x268
el0_svc_common.constprop.0+0x178/0x258
do_el0_svc+0x4c/0x70--- drivers/staging/media/meson/vdec/vdec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/staging/media/meson/vdec/vdec.c +3 -1
@@ -897,7 +897,7 @@ static int vdec_open(struct file *file) ret =vdec_init_ctrls (sess);if (ret) - goto err_m2m_release; + goto err_m2m_ctx_release; sess->pixfmt_cap = formats[0 ].pixfmts_cap[0 ]; sess->fmt_out = &formats[0 ];
@@ -922,6 +922,8 @@ static int vdec_open(struct file *file)return 0 ; +err_m2m_ctx_release: +v4l2_m2m_ctx_release (sess->m2m_ctx); err_m2m_release:v4l2_m2m_release (sess->m2m_dev); err_free_sess:
Greg Kroah-Hartman
maintainerPATCH 198/609 media: msi2500: Return queued buffers on start_streaming() failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Valery Borovsky <[email protected]>
commit 7201c17786a498497bca57752883b90914d405ac upstream.
The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak.
msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls:
- -ENODEV when the USB device was already disconnected
- -ERESTARTSYS when mutex_lock_interruptible() was interrupted
- msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely
- msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret
- msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them
Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining.
The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
--- drivers/media/usb/msi2500/msi2500.c | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-)
drivers/media/usb/msi2500/msi2500.c +24 -8
@@ -541,7 +541,8 @@ static int msi2500_isoc_init(struct msi2 }/* Must be called with vb_queue_lock hold */ -static void msi2500_cleanup_queued_bufs (struct msi2500_dev *dev) +static void msi2500_cleanup_queued_bufs (struct msi2500_dev *dev, +enum vb2_buffer_state state) {unsigned long flags;
@@ -554,7 +555,7 @@ static void msi2500_cleanup_queued_bufs( buf =list_entry (dev->queued_bufs.next, struct msi2500_frame_buf, list);list_del (&buf->list); -vb2_buffer_done (&buf->vb.vb2_buf,VB2_BUF_STATE_ERROR ); +vb2_buffer_done (&buf->vb.vb2_buf, state); }spin_unlock_irqrestore (&dev->queued_bufs_lock, flags); }
@@ -830,25 +831,40 @@ static int msi2500_start_streaming(strucdev_dbg (dev->dev,"\n" ); -if (!dev->udev) -return -ENODEV ; +if (!dev->udev) { + ret = -ENODEV ; + goto err_cleanup; + } -if (mutex_lock_interruptible (&dev->v4l2_lock)) -return -ERESTARTSYS ; +if (mutex_lock_interruptible (&dev->v4l2_lock)) { + ret = -ERESTARTSYS ; + goto err_cleanup; + }/* wake-up tuner */ v4l2_subdev_call (dev->v4l2_subdev, core, s_power,1 ); ret =msi2500_set_usb_adc (dev); +if (ret) + goto err_unlock_cleanup; ret =msi2500_isoc_init (dev);if (ret) -msi2500_cleanup_queued_bufs (dev); + goto err_unlock_cleanup; ret =msi2500_ctrl_msg (dev,CMD_START_STREAMING ,0 ); +if (ret) + goto err_isoc_cleanup;mutex_unlock (&dev->v4l2_lock); +return 0 ; +err_isoc_cleanup: +msi2500_isoc_cleanup (dev); +err_unlock_cleanup: +mutex_unlock (&dev->v4l2_lock); +err_cleanup: +msi2500_cleanup_queued_bufs (dev,VB2_BUF_STATE_QUEUED );return ret; }
@@ -863,7 +879,7 @@ static void msi2500_stop_streaming(strucif (dev->udev)msi2500_isoc_cleanup (dev); -msi2500_cleanup_queued_bufs (dev); +msi2500_cleanup_queued_bufs (dev,VB2_BUF_STATE_ERROR );/* according to tests, at least 700us delay is required */ msleep (20 );
Greg Kroah-Hartman
maintainerPATCH 199/609 media: pci: dm1105: Free allocated workqueue
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 1a65db225b25bb8c8febf16974c060e0cc242eb9 upstream.
Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.
--- drivers/media/pci/dm1105/dm1105.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/pci/dm1105/dm1105.c +1 -0
@@ -1193,6 +1193,7 @@ static void dm1105_remove(struct pci_devdm1105_hw_exit (dev);free_irq (pdev->irq, dev); +destroy_workqueue (dev->wq);pci_iounmap (pdev, dev->io_mem);pci_release_regions (pdev);pci_disable_device (pdev);
Greg Kroah-Hartman
maintainerPATCH 200/609 media: pwc: Drain fill_buf on start_streaming() failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Valery Borovsky <[email protected]>
commit 906e410dcffbbd99fb4081abab817a830033aa28 upstream.
pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes:
start_streaming()
pwc_isoc_init()
usb_submit_urb(urbs[0], GFP_KERNEL)
pwc_isoc_handler(urbs[0])
pdev->fill_buf =
pwc_get_next_fill_buf(pdev)
usb_submit_urb(urbs[i>0], ..) -> fails
pwc_isoc_cleanup(pdev) /* kills URBs */
return ret;
pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED)pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count).
stop_streaming() already handles this since commit 80b0963e1698 ("[media] pwc: fix WARN_ON"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver.
Issue identified by automated review of the INV-003 series at
https://sashiko.dev/
--- drivers/media/usb/pwc/pwc-if.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/media/usb/pwc/pwc-if.c +5 -0
@@ -727,6 +727,11 @@ static int start_streaming(struct vb2_qupwc_camera_power (pdev,0 );/* And cleanup any queued bufs!! */ pwc_cleanup_queued_bufs (pdev,VB2_BUF_STATE_QUEUED ); +if (pdev->fill_buf) { +vb2_buffer_done (&pdev->fill_buf->vb.vb2_buf, +VB2_BUF_STATE_QUEUED ); + pdev->fill_buf =NULL ; + } }mutex_unlock (&pdev->v4l2_lock);
Greg Kroah-Hartman
maintainerPATCH 201/609 media: pwc: Return queued buffers on start_streaming() failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Valery Borovsky <[email protected]>
commit 975b2ee20e569d47821e4f6c9761b4664d48a6a4 upstream.
The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak.
pwc's start_streaming() had two early returns that hit this trap:-ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function).
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
--- drivers/media/usb/pwc/pwc-if.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/media/usb/pwc/pwc-if.c +6 -2
@@ -711,11 +711,15 @@ static int start_streaming(struct vb2_qustruct pwc_device *pdev =vb2_get_drv_priv (vq);int r; -if (!pdev->udev) +if (!pdev->udev) { +pwc_cleanup_queued_bufs (pdev,VB2_BUF_STATE_QUEUED );return -ENODEV ; + } -if (mutex_lock_interruptible (&pdev->v4l2_lock)) +if (mutex_lock_interruptible (&pdev->v4l2_lock)) { +pwc_cleanup_queued_bufs (pdev,VB2_BUF_STATE_QUEUED );return -ERESTARTSYS ; + }/* Turn on camera and set LEDS on */ pwc_camera_power (pdev,1 );pwc_set_leds (pdev, leds[0 ], leds[1 ]);
Greg Kroah-Hartman
maintainerPATCH 202/609 media: radio-si476x: Unregister v4l2_device on probe failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Myeonghun Pak <[email protected]>
commit 436a693af04ffb889aaf87cb69ec1f2b21d3569c upstream.
si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler.
A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path.
Unregister the V4L2 device in the probe error path after freeing the controls.
--- drivers/media/radio/radio-si476x.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/radio/radio-si476x.c +1 -0
@@ -1495,6 +1495,7 @@ static int si476x_radio_probe(struct plareturn 0 ; exit:v4l2_ctrl_handler_free (radio->videodev.ctrl_handler); +v4l2_device_unregister (&radio->v4l2dev);return rval; }
Greg Kroah-Hartman
maintainerPATCH 203/609 media: rtl2832: fix use-after-free in rtl2832_remove()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepanshu Kartikey <[email protected]>
commit 680daf40a82d483949f87f0d8f98639dc47e610c upstream.
cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread.
During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called.
Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.
--- drivers/media/dvb-frontends/rtl2832.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/media/dvb-frontends/rtl2832.c +2 -2
@@ -1116,10 +1116,10 @@ static void rtl2832_remove(struct i2c_cldev_dbg (&client->dev,"\n" ); -cancel_delayed_work_sync (&dev->i2c_gate_work); -i2c_mux_del_adapters (dev->muxc); +cancel_delayed_work_sync (&dev->i2c_gate_work); +regmap_exit (dev->regmap);kfree (dev);
Greg Kroah-Hartman
maintainerPATCH 204/609 media: rtl2832_sdr: Return queued buffers on start_streaming() failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Valery Borovsky <[email protected]>
commit 33ca0aab6f4bd90921fc1395478f38f72c4d19af upstream.
The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak.
rtl2832_sdr_start_streaming() had multiple error paths that hit this
trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six goto err paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers.
The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and "return ret". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return.
The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.
--- drivers/media/dvb-frontends/rtl2832_sdr.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)
drivers/media/dvb-frontends/rtl2832_sdr.c +14 -5
@@ -399,7 +399,8 @@ static int rtl2832_sdr_alloc_urbs(struct }/* Must be called with vb_queue_lock hold */ -static void rtl2832_sdr_cleanup_queued_bufs (struct rtl2832_sdr_dev *dev) +static void rtl2832_sdr_cleanup_queued_bufs (struct rtl2832_sdr_dev *dev, +enum vb2_buffer_state state) {struct platform_device *pdev = dev->pdev;unsigned long flags;
@@ -413,7 +414,7 @@ static void rtl2832_sdr_cleanup_queued_b buf =list_entry (dev->queued_bufs.next, struct rtl2832_sdr_frame_buf, list);list_del (&buf->list); -vb2_buffer_done (&buf->vb.vb2_buf,VB2_BUF_STATE_ERROR ); +vb2_buffer_done (&buf->vb.vb2_buf, state); }spin_unlock_irqrestore (&dev->queued_bufs_lock, flags); }
@@ -854,11 +855,15 @@ static int rtl2832_sdr_start_streaming(sdev_dbg (&pdev->dev,"\n" ); -if (!dev->udev) +if (!dev->udev) { +rtl2832_sdr_cleanup_queued_bufs (dev,VB2_BUF_STATE_QUEUED );return -ENODEV ; + } -if (mutex_lock_interruptible (&dev->v4l2_lock)) +if (mutex_lock_interruptible (&dev->v4l2_lock)) { +rtl2832_sdr_cleanup_queued_bufs (dev,VB2_BUF_STATE_QUEUED );return -ERESTARTSYS ; + }if (d->props->power_ctrl) d->props->power_ctrl (d,1 );
@@ -899,7 +904,11 @@ static int rtl2832_sdr_start_streaming(sif (ret) goto err; +mutex_unlock (&dev->v4l2_lock); +return 0 ; + err: +rtl2832_sdr_cleanup_queued_bufs (dev,VB2_BUF_STATE_QUEUED );mutex_unlock (&dev->v4l2_lock);return ret;
@@ -919,7 +928,7 @@ static void rtl2832_sdr_stop_streaming(srtl2832_sdr_kill_urbs (dev);rtl2832_sdr_free_urbs (dev);rtl2832_sdr_free_stream_bufs (dev); -rtl2832_sdr_cleanup_queued_bufs (dev); +rtl2832_sdr_cleanup_queued_bufs (dev,VB2_BUF_STATE_ERROR );rtl2832_sdr_unset_adc (dev);/* sleep tuner */
Greg Kroah-Hartman
maintainerPATCH 205/609 media: saa7134: Fix a possible memory leak in saa7134_video_init1
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Ke <[email protected]>
commit f86ed548386e3050e5f8f25b450d09dc009d9a88 upstream.
In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources.
Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage.
Found by code review.
--- drivers/media/pci/saa7134/saa7134-video.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-)
drivers/media/pci/saa7134/saa7134-video.c +20 -5
@@ -2119,8 +2119,10 @@ int saa7134_video_init1(struct saa7134_d q->dev = &dev->pci->dev; ret =vb2_queue_init (q);if (ret) -return ret; -saa7134_pgtable_alloc (dev->pci, &dev->video_q.pt); + goto err_free_ctrl; + ret =saa7134_pgtable_alloc (dev->pci, &dev->video_q.pt); +if (ret) + goto err_free_ctrl; q = &dev->vbi_vbq; q->type =V4L2_BUF_TYPE_VBI_CAPTURE ;
@@ -2137,11 +2139,24 @@ int saa7134_video_init1(struct saa7134_d q->lock = &dev->lock; q->dev = &dev->pci->dev; ret =vb2_queue_init (q); -if (ret) -return ret; -saa7134_pgtable_alloc (dev->pci, &dev->vbi_q.pt); +if (ret) { +saa7134_pgtable_free (dev->pci, &dev->video_q.pt); + goto err_free_ctrl; + } + + ret =saa7134_pgtable_alloc (dev->pci, &dev->vbi_q.pt); +if (ret) { +saa7134_pgtable_free (dev->pci, &dev->video_q.pt); + goto err_free_ctrl; + }return 0 ; + +err_free_ctrl: +v4l2_ctrl_handler_free (&dev->ctrl_handler); +if (card_has_radio (dev)) +v4l2_ctrl_handler_free (&dev->radio_ctrl_handler); +return ret; }void saa7134_video_fini (struct saa7134_dev *dev)
Greg Kroah-Hartman
maintainerPATCH 206/609 media: stm32: dcmi: unregister notifier on probe failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Myeonghun Pak <[email protected]>
commit 084973ebd67b28f0945c5d45408f86c58b540110 upstream.
dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove().
Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules.
--- drivers/media/platform/st/stm32/stm32-dcmi.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/platform/st/stm32/stm32-dcmi.c +1 -0
@@ -2122,6 +2122,7 @@ static int dcmi_probe(struct platform_dereturn 0 ; err_cleanup: +v4l2_async_nf_unregister (&dcmi->notifier);v4l2_async_nf_cleanup (&dcmi->notifier); err_media_entity_cleanup:media_entity_cleanup (&dcmi->vdev->entity);
Greg Kroah-Hartman
maintainerPATCH 207/609 media: sun4i-csi: Return queued buffers on start_streaming() failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Valery Borovsky <[email protected]>
commit bbba3e260a62810a717b4442a3bb96d0ec0f6309 upstream.
The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak.
sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
--- drivers/media/platform/sunxi/sun4i-csi/sun4i_dma.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/media/platform/sunxi/sun4i-csi/sun4i_dma.c +4 -2
@@ -234,8 +234,10 @@ static int sun4i_csi_start_streaming(strint ret; csi_fmt =sun4i_csi_find_format (&csi->fmt.pixelformat,NULL ); -if (!csi_fmt) -return -EINVAL ; +if (!csi_fmt) { + ret = -EINVAL ; + goto err_clear_dma_queue; + }dev_dbg (csi->dev,"Starting capture\n" );
Greg Kroah-Hartman
maintainerPATCH 208/609 media: tegra-video: vi: fix invalid u32 return value in format lookup
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hungyu Lin <[email protected]>
commit d5b50055338e131a1a99f923ebb0361974a00f36 upstream.
tegra_get_format_fourcc_by_idx() returns a u32 but uses -EINVAL to signal an out-of-bounds index. This results in a large unsigned value being returned, which may be interpreted as a valid fourcc.
Returning 0 is not a valid fourcc either. This condition should never happen, so use WARN_ON_ONCE() to catch unexpected out-of-bounds access and return a valid fallback format instead.
--- drivers/staging/media/tegra-video/vi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/staging/media/tegra-video/vi.c +2 -2
@@ -76,8 +76,8 @@ static int tegra_get_format_idx_by_code(static u32 tegra_get_format_fourcc_by_idx (struct tegra_vi *vi,unsigned int index) { -if (index >= vi->soc->nformats) -return -EINVAL ; +if (WARN_ON_ONCE (index >= vi->soc->nformats)) +return vi->soc->video_formats[0 ].fourcc;return vi->soc->video_formats[index].fourcc; }
Greg Kroah-Hartman
maintainerPATCH 209/609 media: ti: vpe: unwind v4l2 device registration on probe error
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Myeonghun Pak <[email protected]>
commit e0f1c9a90ef665f2587c274a8fed59f2dfc575a6 upstream.
If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path.
Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().
--- drivers/media/platform/ti/vpe/vpe.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/media/platform/ti/vpe/vpe.c +2 -1
@@ -2545,7 +2545,8 @@ static int vpe_probe(struct platform_dev "vpe_top");if (!dev->res) {dev_err (&pdev->dev,"missing 'vpe_top' resources data\n" ); -return -ENODEV ; + ret = -ENODEV ; + goto v4l2_dev_unreg; }/*
Greg Kroah-Hartman
maintainerPATCH 210/609 media: v4l2-ctrls-request: add NULL check in v4l2_ctrl_request_complete()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Shtylyov <[email protected]>
commit caced3578bf9f104a4aaad8f46c4c719e705d9a6 upstream.
If CONFIG_MEDIA_CONTROLLER is undefined, media_request_object_find() will always return NULL, so its 2nd call in v4l2_ctrl_request_complete() would fail as well as the 1st one and thus cause hdl to have a wrong value (at the top of memory) and list_for_each_entry() to iterate over the garbage data located there. Add NULL check for the 2nd call and place the error cleanup at the end of v4l2_ctrl_request_complete()...
Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.
--- drivers/media/v4l2-core/v4l2-ctrls-request.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
drivers/media/v4l2-core/v4l2-ctrls-request.c +9 -5
@@ -348,13 +348,12 @@ void v4l2_ctrl_request_complete(struct m ret =v4l2_ctrl_handler_init (hdl, (main_hdl->nr_of_buckets -1 ) *8 );if (!ret) ret =v4l2_ctrl_request_bind (req, hdl, main_hdl); -if (ret) { -v4l2_ctrl_handler_free (hdl); -kfree (hdl); -return ; - } +if (ret) + goto error; hdl->request_is_queued = true; obj =media_request_object_find (req, &req_ops, main_hdl); +if (!obj) + goto error; } hdl = container_of(obj, struct v4l2_ctrl_handler, req_obj);
@@ -389,6 +388,11 @@ void v4l2_ctrl_request_complete(struct mmutex_unlock (main_hdl->lock);media_request_object_complete (obj);media_request_object_put (obj); +return ; + +error: +v4l2_ctrl_handler_free (hdl); +kfree (hdl); }EXPORT_SYMBOL (v4l2_ctrl_request_complete);
Greg Kroah-Hartman
maintainerPATCH 211/609 media: v4l2-ctrls: validate HEVC active reference counts
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pengpeng Hou <[email protected]>
commit afbe4bc252d90a6f8fad869b06d5430f615f22f9 upstream.
HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them.
The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued.
Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.
--- drivers/media/v4l2-core/v4l2-ctrls-core.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/media/v4l2-core/v4l2-ctrls-core.c +13 -0
@@ -566,6 +566,7 @@ static int std_validate_compound(const sstruct v4l2_ctrl_h264_decode_params *p_h264_dec_params;struct v4l2_ctrl_hevc_sps *p_hevc_sps;struct v4l2_ctrl_hevc_pps *p_hevc_pps; +struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params;struct v4l2_ctrl_hdr10_mastering_display *p_hdr10_mastering;struct v4l2_ctrl_hevc_decode_params *p_hevc_decode_params;struct v4l2_area *area;
@@ -854,6 +855,18 @@ static int std_validate_compound(const sbreak ;case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS : + p_hevc_slice_params = p; + +if (p_hevc_slice_params->num_ref_idx_l0_active_minus1 >= +V4L2_HEVC_DPB_ENTRIES_NUM_MAX ) +return -EINVAL ; + +if (p_hevc_slice_params->slice_type !=V4L2_HEVC_SLICE_TYPE_B ) +break ; + +if (p_hevc_slice_params->num_ref_idx_l1_active_minus1 >= +V4L2_HEVC_DPB_ENTRIES_NUM_MAX ) +return -EINVAL ;break ;case V4L2_CTRL_TYPE_HDR10_CLL_INFO :
Greg Kroah-Hartman
maintainerPATCH 212/609 media: vb2: use ssize_t for vb2_read/vb2_write
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zile Xiong <[email protected]>
commit a562d6dc86bdfdd299e1b4734977a8d63e803583 upstream.
vb2_read() and vb2_write() return size_t, but propagate negative errno values from __vb2_perform_fileio().
This relies on implicit signed/unsigned conversions in callers (e.g. vb2_fop_read()) to recover error codes:
__vb2_perform_fileio() -> -EINVAL
vb2_read() -> (size_t)-EINVAL
vb2_fop_read() -> -EINVALThis relies on implicit conversions that are not obvious.
These helpers are exported (EXPORT_SYMBOL_GPL) and part of the vb2 API, so changing their return type may affect existing users.
However, they conceptually follow read/write semantics, where ssize_t is typically used to return either a byte count or a negative error code.
Switch vb2_read() and vb2_write() to ssize_t, and update __vb2_perform_fileio() accordingly.
--- drivers/media/common/videobuf2/videobuf2-core.c | 12 ++++++------ include/media/videobuf2-core.h | 8 ++++---- 2 files changed, 10 insertions(+), 10 deletions(-)
drivers/media/common/videobuf2/videobuf2-core.c +6 -6
@@ -2770,8 +2770,8 @@ static int __vb2_cleanup_fileio(struct v* @nonblock: mode selector (1 means blocking calls, 0 means nonblocking) * @read: access mode selector (1 means read, 0 means write) */ -static size_t __vb2_perform_fileio (struct vb2_queue *q,char __user *data,size_t count, -loff_t *ppos,int nonblock,int read) +static ssize_t __vb2_perform_fileio (struct vb2_queue *q,char __user *data,size_t count, +loff_t *ppos,int nonblock,int read) {struct vb2_fileio_data *fileio;struct vb2_fileio_buf *buf;
@@ -2931,15 +2931,15 @@ static size_t __vb2_perform_fileio(strucreturn ret; } -size_t vb2_read (struct vb2_queue *q,char __user *data,size_t count, -loff_t *ppos,int nonblocking) +ssize_t vb2_read (struct vb2_queue *q,char __user *data,size_t count, +loff_t *ppos,int nonblocking) {return __vb2_perform_fileio (q, data, count, ppos, nonblocking,1 ); }EXPORT_SYMBOL_GPL (vb2_read); -size_t vb2_write (struct vb2_queue *q,const char __user *data,size_t count, -loff_t *ppos,int nonblocking) +ssize_t vb2_write (struct vb2_queue *q,const char __user *data,size_t count, +loff_t *ppos,int nonblocking) {return __vb2_perform_fileio (q, (char __user *) data, count, ppos, nonblocking,0 );
include/media/videobuf2-core.h +4 -4
@@ -1050,8 +1050,8 @@ __poll_t vb2_core_poll(struct vb2_queue* @ppos: file handle position tracking pointer * @nonblock: mode selector (1 means blocking calls, 0 means nonblocking) */ -size_t vb2_read (struct vb2_queue *q,char __user *data,size_t count, -loff_t *ppos,int nonblock); +ssize_t vb2_read (struct vb2_queue *q,char __user *data,size_t count, +loff_t *ppos,int nonblock);/** * vb2_write() - implements write() syscall logic. * @q: pointer to &struct vb2_queue with videobuf2 queue.
@@ -1060,8 +1060,8 @@ size_t vb2_read(struct vb2_queue *q, cha* @ppos: file handle position tracking pointer * @nonblock: mode selector (1 means blocking calls, 0 means nonblocking) */ -size_t vb2_write (struct vb2_queue *q,const char __user *data,size_t count, -loff_t *ppos,int nonblock); +ssize_t vb2_write (struct vb2_queue *q,const char __user *data,size_t count, +loff_t *ppos,int nonblock);/** * typedef vb2_thread_fnc - callback function for use with vb2_thread.
Greg Kroah-Hartman
maintainerPATCH 213/609 media: vidtv: fix reference leak on failed device registration
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guangshuo Li <[email protected]>
commit 9aa21e1549db8882ff77b691e7714153df21dff0 upstream.
When platform_device_register() fails in vidtv_bridge_init(), the embedded struct device in vidtv_bridge_dev has already been initialized by device_initialize(), but the failure path returns the error without dropping the device reference for the current platform device:
vidtv_bridge_init()
-> platform_device_register(&vidtv_bridge_dev)
-> device_initialize(&vidtv_bridge_dev.dev)
-> setup_pdev_dma_masks(&vidtv_bridge_dev)
-> platform_device_add(&vidtv_bridge_dev)This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and confirmed by manual review.
--- drivers/media/test-drivers/vidtv/vidtv_bridge.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/media/test-drivers/vidtv/vidtv_bridge.c +3 -1
@@ -596,8 +596,10 @@ static int __init vidtv_bridge_init(voidint ret; ret =platform_device_register (&vidtv_bridge_dev); -if (ret) +if (ret) { +platform_device_put (&vidtv_bridge_dev);return ret; + } ret =platform_driver_register (&vidtv_bridge_driver);if (ret)
Greg Kroah-Hartman
maintainerPATCH 214/609 media: vimc: fix reference leak on failed device registration
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guangshuo Li <[email protected]>
commit 33e2b833c66b890a0d71c4fa82d4c97143f7f75f upstream.
When platform_device_register() fails in vimc_init(), the embedded struct device in vimc_pdev has already been initialized by device_initialize(), but the failure path returns the error without dropping the device reference for the current platform device:
vimc_init()
-> platform_device_register(&vimc_pdev)
-> device_initialize(&vimc_pdev.dev)
-> setup_pdev_dma_masks(&vimc_pdev)
-> platform_device_add(&vimc_pdev)This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and confirmed by manual review.
--- drivers/media/test-drivers/vimc/vimc-core.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/test-drivers/vimc/vimc-core.c +1 -0
@@ -426,6 +426,7 @@ static int __init vimc_init(void)if (ret) {dev_err (&vimc_pdev.dev,"platform device registration failed (err=%d)\n" , ret); +platform_device_put (&vimc_pdev);return ret; }
Greg Kroah-Hartman
maintainerPATCH 215/609 media: vivid: add vivid_update_reduced_fps()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
commit 1d793a29efb4260f90913f5287939bf95573b073 upstream.
Don't call vivid_update_format_cap() when switching to/from reduced fps for HDMI inputs: that will also reset the format, which is overkill for this.
Make a new vivid_update_reduced_fps() function that just updates the dev->timeperframe_vid_cap.
--- drivers/media/test-drivers/vivid/vivid-ctrls.c | 3 +- drivers/media/test-drivers/vivid/vivid-vid-cap.c | 32 +++++++++++++---------- drivers/media/test-drivers/vivid/vivid-vid-cap.h | 1 3 files changed, 22 insertions(+), 14 deletions(-)
drivers/media/test-drivers/vivid/vivid-ctrls.c +2 -1
@@ -516,7 +516,8 @@ static int vivid_vid_cap_s_ctrl(struct vbreak ;case VIVID_CID_REDUCED_FPS : dev->reduced_fps = ctrl->val; -vivid_update_format_cap (dev, true); +if (dev->input_type[dev->input] ==HDMI ) +vivid_update_reduced_fps (dev);break ;case VIVID_CID_HAS_CROP_CAP : dev->has_crop_cap = ctrl->val;
drivers/media/test-drivers/vivid/vivid-vid-cap.c +19 -13
@@ -375,6 +375,24 @@ static enum tpg_pixel_aspect vivid_get_preturn TPG_PIXEL_ASPECT_SQUARE ; } +void vivid_update_reduced_fps (struct vivid_dev *dev) +{ +struct v4l2_bt_timings *bt = &dev->dv_timings_cap[dev->input].bt; +unsigned int size =V4L2_DV_BT_FRAME_WIDTH (bt) *V4L2_DV_BT_FRAME_HEIGHT (bt); +u64 pixelclock; + +if (dev->reduced_fps &&can_reduce_fps (bt)) { + pixelclock =div_u64 (bt->pixelclock *1000 ,1001 ); + bt->flags |=V4L2_DV_FL_REDUCED_FPS ; + }else { + pixelclock = bt->pixelclock; + bt->flags &= ~V4L2_DV_FL_REDUCED_FPS ; + } + dev->timeperframe_vid_cap = (struct v4l2_fract ) { + size /100 , (u32 )pixelclock /100 + }; +} +/* * Called whenever the format has to be reset which can occur when * changing inputs, standard, timings, etc.
@@ -383,8 +401,6 @@ void vivid_update_format_cap(struct vivi {struct v4l2_bt_timings *bt = &dev->dv_timings_cap[dev->input].bt;u32 dims[V4L2_CTRL_MAX_DIMS ] = {}; -unsigned size; -u64 pixelclock;switch (dev->input_type[dev->input]) {case WEBCAM :
@@ -413,17 +429,7 @@ void vivid_update_format_cap(struct vivicase HDMI : dev->src_rect.width = bt->width; dev->src_rect.height = bt->height; - size =V4L2_DV_BT_FRAME_WIDTH (bt) *V4L2_DV_BT_FRAME_HEIGHT (bt); -if (dev->reduced_fps &&can_reduce_fps (bt)) { - pixelclock =div_u64 (bt->pixelclock *1000 ,1001 ); - bt->flags |=V4L2_DV_FL_REDUCED_FPS ; - }else { - pixelclock = bt->pixelclock; - bt->flags &= ~V4L2_DV_FL_REDUCED_FPS ; - } - dev->timeperframe_vid_cap = (struct v4l2_fract ) { - size /100 , (u32 )pixelclock /100 - }; +vivid_update_reduced_fps (dev);if (bt->interlaced) dev->field_cap =V4L2_FIELD_ALTERNATE ;else
drivers/media/test-drivers/vivid/vivid-vid-cap.h +1 -0
@@ -9,6 +9,7 @@#define _VIVID_VID_CAP_H_void vivid_update_quality (struct vivid_dev *dev); +void vivid_update_reduced_fps (struct vivid_dev *dev);void vivid_update_format_cap (struct vivid_dev *dev,bool keep_controls);enum tpg_video_aspect vivid_get_video_aspect (const struct vivid_dev *dev);
Greg Kroah-Hartman
maintainerPATCH 216/609 media: vivid: check for vb2_is_busy() when toggling caps
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
commit c2d1a2130c93f6d758af58590b86b2254c7a1dec upstream.
The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked.
Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results.
Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy.
I'm 90% certain that this is the cause of this syzbot bug:
https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89
But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.
--- drivers/media/test-drivers/vivid/vivid-ctrls.c | 12 ++++++++++++ drivers/media/test-drivers/vivid/vivid-vid-cap.c | 6 ++++++ drivers/media/test-drivers/vivid/vivid-vid-out.c | 6 ++++++ 3 files changed, 24 insertions(+)
drivers/media/test-drivers/vivid/vivid-ctrls.c +12 -0
@@ -520,14 +520,20 @@ static int vivid_vid_cap_s_ctrl(struct vvivid_update_reduced_fps (dev);break ;case VIVID_CID_HAS_CROP_CAP : +if (vb2_is_busy (&dev->vb_vid_cap_q)) +return -EBUSY ; dev->has_crop_cap = ctrl->val;vivid_update_format_cap (dev, true);break ;case VIVID_CID_HAS_COMPOSE_CAP : +if (vb2_is_busy (&dev->vb_vid_cap_q)) +return -EBUSY ; dev->has_compose_cap = ctrl->val;vivid_update_format_cap (dev, true);break ;case VIVID_CID_HAS_SCALER_CAP : +if (vb2_is_busy (&dev->vb_vid_cap_q)) +return -EBUSY ; dev->has_scaler_cap = ctrl->val;vivid_update_format_cap (dev, true);break ;
@@ -1012,14 +1018,20 @@ static int vivid_vid_out_s_ctrl(struct vswitch (ctrl->id) {case VIVID_CID_HAS_CROP_OUT : +if (vb2_is_busy (&dev->vb_vid_out_q)) +return -EBUSY ; dev->has_crop_out = ctrl->val;vivid_update_format_out (dev);break ;case VIVID_CID_HAS_COMPOSE_OUT : +if (vb2_is_busy (&dev->vb_vid_out_q)) +return -EBUSY ; dev->has_compose_out = ctrl->val;vivid_update_format_out (dev);break ;case VIVID_CID_HAS_SCALER_OUT : +if (vb2_is_busy (&dev->vb_vid_out_q)) +return -EBUSY ; dev->has_scaler_out = ctrl->val;vivid_update_format_out (dev);break ;
drivers/media/test-drivers/vivid/vivid-vid-cap.c +6 -0
@@ -402,6 +402,12 @@ void vivid_update_format_cap(struct vivistruct v4l2_bt_timings *bt = &dev->dv_timings_cap[dev->input].bt;u32 dims[V4L2_CTRL_MAX_DIMS ] = {}; +/* +* This resets the format, so must never be called while vb2_is_busy(). +*/ +if (WARN_ON (vb2_is_busy (&dev->vb_vid_cap_q))) +return ; +switch (dev->input_type[dev->input]) {case WEBCAM :default :
drivers/media/test-drivers/vivid/vivid-vid-out.c +6 -0
@@ -222,6 +222,12 @@ void vivid_update_format_out(struct viviunsigned size, p;u64 pixelclock; +/* +* This resets the format, so must never be called while vb2_is_busy(). +*/ +if (WARN_ON (vb2_is_busy (&dev->vb_vid_out_q))) +return ; +switch (dev->output_type[dev->output]) {case SVID :default :
Greg Kroah-Hartman
maintainerPATCH 217/609 media: vpif_capture: fix OF node reference imbalance
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 2282f979560af6bbc8ee2c1ee8663197312cee5b upstream.
The driver reuses the OF node of the parent device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the parent and releasing the child devices.
Fix this by using the intended helper for reusing OF nodes.
--- drivers/media/platform/ti/davinci/vpif_capture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/platform/ti/davinci/vpif_capture.c +1 -1
@@ -1499,7 +1499,7 @@ vpif_capture_get_pdata(struct platform_d* video ports & endpoints data. */ if (pdev->dev.parent && pdev->dev.parent->of_node) - pdev->dev.of_node = pdev->dev.parent->of_node; +device_set_of_node_from_dev (&pdev->dev, pdev->dev.parent);if (!IS_ENABLED (CONFIG_OF ) || !pdev->dev.of_node)return pdev->dev.platform_data;
Greg Kroah-Hartman
maintainerPATCH 218/609 ALSA: seq: close a re-opened queue timer in the destructor
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Norbert Szetei <[email protected]>
commit 2c4dc0ed50b05cd847a4b34b8cebf0775f19aeb9 upstream.
queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer.
A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri.
snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next.
The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt().
Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required.
Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.
--- sound/core/seq/seq_timer.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
sound/core/seq/seq_timer.c +12 -1
@@ -58,12 +58,23 @@ struct snd_seq_timer *snd_seq_timer_new(void snd_seq_timer_delete (struct snd_seq_timer **tmr) {struct snd_seq_timer *t = *tmr; - *tmr =NULL ; +struct snd_timer_instance *ti;if (t ==NULL ) {pr_debug ("ALSA: seq: snd_seq_timer_delete() called with NULL timer\n" );return ; } + + scoped_guard(spinlock_irq, &t->lock) { + ti = t->timeri; + t->timeri =NULL ; + } +if (ti) { +snd_timer_close (ti); +snd_timer_instance_free (ti); + } + + *tmr =NULL ; t->running =0 ;/* reset time */
Greg Kroah-Hartman
maintainerPATCH 219/609 wifi: ath6kl: fix OOB access from firmware ADDBA window size
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tristan Madani <[email protected]>
commit 44126b6994eeb28f2103b638e698f40a1244f327 upstream.
aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access.
Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.
--- drivers/net/wireless/ath/ath6kl/txrx.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/net/wireless/ath/ath6kl/txrx.c +6 -4
@@ -1722,13 +1722,15 @@ void aggr_recv_addba_req_evt(struct ath6 rxtid = &aggr_conn->rx_tid[tid]; -if (win_sz <AGGR_WIN_SZ_MIN || win_sz >AGGR_WIN_SZ_MAX ) -ath6kl_dbg (ATH6KL_DBG_WLAN_RX ,"%s: win_sz %d, tid %d\n" , - __func__, win_sz, tid); -if (rxtid->aggr)aggr_delete_tid_state (aggr_conn, tid); +if (win_sz <AGGR_WIN_SZ_MIN || win_sz >AGGR_WIN_SZ_MAX ) { +ath6kl_dbg (ATH6KL_DBG_WLAN_RX ,"%s: win_sz %d, tid %d\n" , + __func__, win_sz, tid); +return ; + } + rxtid->seq_next = seq_no; hold_q_size =TID_WINDOW_SZ (win_sz) *sizeof (struct skb_hold_q ); rxtid->hold_q =kzalloc (hold_q_size,GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 220/609 wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Doruk Tan Ozturk <[email protected]>
commit c3d68e294cbb6a4090bb219d3dcaca85a011809b upstream.
mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper:
if (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && bss_desc->bcn_ht_cap && ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param))
bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first.
Guard on the pointer that is actually dereferenced.
Found by 0sec automated security-research tooling (https://0sec.ai).
--- drivers/net/wireless/marvell/mwifiex/tdls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/marvell/mwifiex/tdls.c +1 -1
@@ -215,7 +215,7 @@ mwifiex_tdls_add_ht_oper(struct mwifiex_/* follow AP's channel bandwidth */ if (ISSUPP_CHANWIDTH40 (priv->adapter->hw_dot_11n_dev_cap) && - bss_desc->bcn_ht_cap && + bss_desc->bcn_ht_oper &&ISALLOWED_CHANWIDTH40 (bss_desc->bcn_ht_oper->ht_param)) ht_oper->ht_param = bss_desc->bcn_ht_oper->ht_param;
Greg Kroah-Hartman
maintainerPATCH 221/609 wifi: wilc1000: validate assoc response length before subtracting header
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huihui Huang <[email protected]>
commit 4c4c97b60a5e978121d9ee8cb0ab3916e5d6a8de upstream.
wilc_parse_assoc_resp_info() computes the trailing IE length as
ies_len = buffer_len - sizeof(*res);
without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header.
For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3.
Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a "conn_info->status == WLAN_STATUS_SUCCESS" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.
--- drivers/net/wireless/microchip/wilc1000/hif.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/wireless/microchip/wilc1000/hif.c +5 -0
@@ -597,6 +597,11 @@ static s32 wilc_parse_assoc_resp_info(u8u16 ies_len;struct wilc_assoc_resp *res = (struct wilc_assoc_resp *)buffer; +if (buffer_len <sizeof (*res)) { + ret_conn_info->status =WLAN_STATUS_UNSPECIFIED_FAILURE ; +return -EINVAL ; + } + ret_conn_info->status =le16_to_cpu (res->status_code);if (ret_conn_info->status ==WLAN_STATUS_SUCCESS ) { ies = &buffer[sizeof (*res)];
Greg Kroah-Hartman
maintainerPATCH 222/609 wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Devin Wittmayer <[email protected]>
commit 39afc46c0243d10b7795e6e6cf4ae91f41732120 upstream.
PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series.
Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices").
--- drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/wireless/mediatek/mt76/mt7615/mac.c +6 -0
@@ -1618,6 +1618,8 @@ bool mt7615_rx_check(struct mt76_dev *mdswitch (type) {case PKT_TYPE_TXRX_NOTIFY : +if (!mt76_is_mmio (mdev)) +return false;mt7615_mac_tx_free (dev, data, len);return false;case PKT_TYPE_TXS :
@@ -1651,6 +1653,10 @@ void mt7615_queue_rx_skb(struct mt76_devdev_kfree_skb (skb);break ;case PKT_TYPE_TXRX_NOTIFY : +if (!mt76_is_mmio (mdev)) { +dev_kfree_skb (skb); +break ; + }mt7615_mac_tx_free (dev, skb->data, skb->len);dev_kfree_skb (skb);break ;
Greg Kroah-Hartman
maintainerPATCH 223/609 wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Devin Wittmayer <[email protected]>
commit da4082e91acabc1498611ed8ccc53f0610baefc6 upstream.
PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker:
BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb]
Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices").
--- drivers/net/wireless/mediatek/mt76/mt7921/mac.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/net/wireless/mediatek/mt76/mt7921/mac.c +7 -3
@@ -678,8 +678,9 @@ bool mt7921_rx_check(struct mt76_dev *mdswitch (type) {case PKT_TYPE_TXRX_NOTIFY : -/* PKT_TYPE_TXRX_NOTIFY can be received only by mmio devices */ -mt7921_mac_tx_free (dev, data, len);/* mmio */ +if (!mt76_is_mmio (mdev)) +return false; +mt7921_mac_tx_free (dev, data, len);return false;case PKT_TYPE_TXS :for (rxd +=2 ; rxd +8 <= end; rxd +=8 )
@@ -708,7 +709,10 @@ void mt7921_queue_rx_skb(struct mt76_devswitch (type) {case PKT_TYPE_TXRX_NOTIFY : -/* PKT_TYPE_TXRX_NOTIFY can be received only by mmio devices */ +if (!mt76_is_mmio (mdev)) { +napi_consume_skb (skb,1 ); +break ; + }mt7921_mac_tx_free (dev, skb->data, skb->len);napi_consume_skb (skb,1 );break ;
Greg Kroah-Hartman
maintainerPATCH 224/609 wifi: brcmfmac: make release_scratchbuffers idempotent
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fan Wu <[email protected]>
commit 538c51e9d124cf656f2dd0c0394a8545efc7102d upstream.
brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release.
Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation.
NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch.
This issue was found by an in-house static analysis tool.
--- drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +6 -2
@@ -1356,16 +1356,20 @@ fail:static void brcmf_pcie_release_scratchbuffers (struct brcmf_pciedev_info *devinfo) { -if (devinfo->shared.scratch) +if (devinfo->shared.scratch) {dma_free_coherent (&devinfo->pdev->dev,BRCMF_DMA_D2H_SCRATCH_BUF_LEN , devinfo->shared.scratch, devinfo->shared.scratch_dmahandle); -if (devinfo->shared.ringupd) + devinfo->shared.scratch =NULL ; + } +if (devinfo->shared.ringupd) {dma_free_coherent (&devinfo->pdev->dev,BRCMF_DMA_D2H_RINGUPD_BUF_LEN , devinfo->shared.ringupd, devinfo->shared.ringupd_dmahandle); + devinfo->shared.ringupd =NULL ; + } }static int brcmf_pcie_init_scratchbuffers (struct brcmf_pciedev_info *devinfo)
Greg Kroah-Hartman
maintainerPATCH 225/609 staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Moksh Panicker <[email protected]>
commit 0e95ff792ae0aa6fbad9455943e9e1e4062670e9 upstream.
rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically:
- in_ie[cnt + 1] is read without checking cnt + 1 < in_len
- memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check
- in_ie[cnt + 1] is used as length without verifying payload fits
Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.
--- drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/staging/rtl8723bs/core/rtw_ieee80211.c +8 -1
@@ -678,7 +678,14 @@ u8 *rtw_get_wps_ie(u8 *in_ie, uint in_lewhile (cnt < in_len) { eid = in_ie[cnt]; -if ((eid ==WLAN_EID_VENDOR_SPECIFIC ) && (!memcmp (&in_ie[cnt +2 ], wps_oui,4 ))) { +if (cnt +2 > in_len) +break ; + +if (in_ie[cnt +1 ] +2 > in_len - cnt) +break ; + +if ((eid ==WLAN_EID_VENDOR_SPECIFIC ) && (in_ie[cnt +1 ] >=4 ) && + (!memcmp (&in_ie[cnt +2 ], wps_oui,4 ))) { wpsie_ptr = &in_ie[cnt];if (wps_ie)
Greg Kroah-Hartman
maintainerPATCH 226/609 staging: rtl8723bs: fix inverted HT40 secondary channel offset
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: MinJea Kim <[email protected]>
commit 30d49cba27f8905bc288cef5846963f0004f644c upstream.
rtw_get_chan_type() maps the driver's channel offset to nl80211 channel types the wrong way around.
In this driver HAL_PRIME_CHNL_OFFSET_LOWER means the primary channel is the lower 20 MHz half of the 40 MHz pair, i.e. the secondary channel is above the primary one: rtw_get_center_ch() computes the center channel as "channel + 2" for OFFSET_LOWER, and bwmode_update_check() sets OFFSET_LOWER when the AP's HT operation IE announces SCA (secondary channel above). In nl80211 terms that is NL80211_CHAN_HT40PLUS, not HT40MINUS.
Because of the inversion, cfg80211_rtw_get_channel() reports an HT40+ association as HT40-. For an HT40+ AP on a low channel (e.g. channel 3) the resulting chandef spans below the 2.4 GHz band edge and is invalid, so the regulatory core tears the connection down 60 seconds (REG_ENFORCE_GRACE_MS) after the AP's country IE triggers a regdomain
change: reg_check_chans_work() considers the reported chandef unusable and calls cfg80211_leave(). The supplicant then reconnects, the country IE changes the regdomain again, and the cycle repeats, causing a disconnect/reconnect loop every ~65 seconds for as long as the link is up.
Observed on a TECLAST X80 Power tablet (RTL8723BS) associated to an HT40+ AP on channel 3 with a KR country IE; a kprobe trace showed cfg80211_disconnect() being invoked from reg_check_chans_work(). With the mapping fixed, "iw dev wlan0 info" reports the correct "width: 40 MHz, center1: 2432 MHz" and the periodic disconnects stop.
--- drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c +1 -1
@@ -1999,7 +1999,7 @@ static u8 rtw_get_chan_type(struct adaptelse return NL80211_CHAN_NO_HT ;case CHANNEL_WIDTH_40 : -if (mlme_ext->cur_ch_offset ==HAL_PRIME_CHNL_OFFSET_UPPER ) +if (mlme_ext->cur_ch_offset ==HAL_PRIME_CHNL_OFFSET_LOWER )return NL80211_CHAN_HT40PLUS ;else return NL80211_CHAN_HT40MINUS ;
Greg Kroah-Hartman
maintainerPATCH 227/609 Bluetooth: hci_sync: Protect UUID list traversal
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chengfeng Ye <[email protected]>
commit e9027ffbf5a0f3c12ca8900822e884eae9f0821b upstream.
The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock.
The following interleaving can therefore occur:
CPU0 (command sync work) CPU1 (management socket)
fetch uuid from the list
list_del(&uuid->list)
kfree(uuid) read uuid->size
KASAN reports the resulting use-after-free:
BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0
Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.
--- net/bluetooth/hci_sync.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
net/bluetooth/hci_sync.c +11 -2
@@ -903,12 +903,16 @@ int hci_update_eir_sync(struct hci_dev *memset (&cp,0 ,sizeof (cp)); +hci_dev_lock (hdev);eir_create (hdev, cp.data); -if (memcmp (cp.data, hdev->eir,sizeof (cp.data)) ==0 ) +if (memcmp (cp.data, hdev->eir,sizeof (cp.data)) ==0 ) { +hci_dev_unlock (hdev);return 0 ; + }memcpy (hdev->eir, cp.data,sizeof (cp.data)); +hci_dev_unlock (hdev);return __hci_cmd_sync_status (hdev,HCI_OP_WRITE_EIR ,sizeof (cp), &cp,HCI_CMD_TIMEOUT );
@@ -940,6 +944,7 @@ int hci_update_class_sync(struct hci_devif (hci_dev_test_flag (hdev,HCI_SERVICE_CACHE ))return 0 ; +hci_dev_lock (hdev); cod[0 ] = hdev->minor_class; cod[1 ] = hdev->major_class; cod[2 ] =get_service_classes (hdev);
@@ -947,8 +952,12 @@ int hci_update_class_sync(struct hci_devif (hci_dev_test_flag (hdev,HCI_LIMITED_DISCOVERABLE )) cod[1 ] |=0x20 ; -if (memcmp (cod, hdev->dev_class,3 ) ==0 ) +if (memcmp (cod, hdev->dev_class,3 ) ==0 ) { +hci_dev_unlock (hdev);return 0 ; + } + +hci_dev_unlock (hdev);return __hci_cmd_sync_status (hdev,HCI_OP_WRITE_CLASS_OF_DEV ,sizeof (cod), cod,HCI_CMD_TIMEOUT );
Greg Kroah-Hartman
maintainerPATCH 228/609 Bluetooth: RFCOMM: Fix session UAF in set_termios
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chengfeng Ye <[email protected]>
commit c783399efc22d035443f1dfbf2a09bf9562aaa5e upstream.
rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex.
The race can proceed as follows:
TTY ioctl task krfcommd
-------------- --------
load dlc->session
enter rfcomm_send_rpn()
lock rfcomm_mutex
clear dlc->session
free session
unlock rfcomm_mutex read session->initiator
KASAN reported:
BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710
Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.
--- include/net/bluetooth/rfcomm.h | 3 +++ net/bluetooth/rfcomm/core.c | 17 +++++++++++++++++ net/bluetooth/rfcomm/tty.c | 7 +++---- 3 files changed, 23 insertions(+), 4 deletions(-)
include/net/bluetooth/rfcomm.h +3 -0
@@ -229,6 +229,9 @@ int rfcomm_send_rpn(struct rfcomm_sessio u8 bit_rate, u8 data_bits, u8 stop_bits, u8 parity, u8 flow_ctrl_settings, u8 xon_char, u8 xoff_char, u16 param_mask); +int rfcomm_dlc_send_rpn (struct rfcomm_dlc *d,u8 bit_rate,u8 data_bits, +u8 stop_bits,u8 parity,u8 flow_ctrl_settings, +u8 xon_char,u8 xoff_char,u16 param_mask);/* ---- RFCOMM DLCs (channels) ---- */ struct rfcomm_dlc *rfcomm_dlc_alloc (gfp_t prio);
net/bluetooth/rfcomm/core.c +17 -0
@@ -1027,6 +1027,23 @@ int rfcomm_send_rpn(struct rfcomm_sessioreturn rfcomm_send_frame (s, buf, ptr - buf); } +int rfcomm_dlc_send_rpn (struct rfcomm_dlc *d,u8 bit_rate,u8 data_bits, +u8 stop_bits,u8 parity,u8 flow_ctrl_settings, +u8 xon_char,u8 xoff_char,u16 param_mask) +{ +int err = -ENOTCONN ; + +rfcomm_lock (); +if (d->session) + err =rfcomm_send_rpn (d->session,1 , d->dlci, bit_rate, + data_bits, stop_bits, parity, + flow_ctrl_settings, xon_char, xoff_char, + param_mask); +rfcomm_unlock (); + +return err; +} +static int rfcomm_send_rls (struct rfcomm_session *s,int cr,u8 dlci,u8 status) {struct rfcomm_hdr *hdr;
net/bluetooth/rfcomm/tty.c +3 -4
@@ -863,7 +863,7 @@ static void rfcomm_tty_set_termios(strucBT_DBG ("tty %p termios %p" , tty, old); -if (!dev || !dev->dlc || !dev->dlc->session) +if (!dev || !dev->dlc)return ;/* Handle turning off CRTSCTS */
@@ -984,9 +984,8 @@ static void rfcomm_tty_set_termios(struc }if (changes) -rfcomm_send_rpn (dev->dlc->session,1 , dev->dlc->dlci, baud, - data_bits, stop_bits, parity, -RFCOMM_RPN_FLOW_NONE , x_on, x_off, changes); +rfcomm_dlc_send_rpn (dev->dlc, baud, data_bits, stop_bits, parity, +RFCOMM_RPN_FLOW_NONE , x_on, x_off, changes); }static void rfcomm_tty_throttle (struct tty_struct *tty)
Greg Kroah-Hartman
maintainerPATCH 229/609 exec: fix unsigned loop counter wrap in transfer_args_to_stack()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit 16cc4f5c1c4b9e45eca7f7deefa5410a292db599 upstream.
The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true.
After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either...
Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left.
bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page:
Oops - load access fault [#1]
CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt
This is an arcane bug but we should still fix it.
Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop.
Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only.
The loop predates git history. commit 7e7ec6a93434 ("elf_fdpic_transfer_args_to_stack(): make it generic") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.
--- fs/exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/exec.c +1 -1
@@ -884,7 +884,7 @@ int transfer_args_to_stack(struct linux_ stop = bprm->p >>PAGE_SHIFT ; sp = *sp_location; -for (index =MAX_ARG_PAGES -1 ; index >= stop; index--) { +for (index =MAX_ARG_PAGES ; index-- > stop; ) {unsigned int offset = index == stop ? bprm->p & ~PAGE_MASK :0 ;char *src =kmap_local_page (bprm->page[index]) + offset; sp -=PAGE_SIZE - offset;
Greg Kroah-Hartman
maintainerPATCH 230/609 binfmt_misc: set have_execfd only once the interpreter is opened
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit bbf5f639918dc011aaf60aab8480218758ee68c5 upstream.
load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present.
Consequently, begin_new_exec() dereferences the missing executable:
would_dump(bprm, bprm->executable);
and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way.
This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry.
have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.
--- fs/binfmt_misc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
fs/binfmt_misc.c +2 -3
@@ -199,9 +199,6 @@ static int load_misc_binary(struct linux goto ret; } -if (fmt->flags &MISC_FMT_OPEN_BINARY ) - bprm->have_execfd =1 ; -/* make argv[1] be the path to the binary */ retval =copy_string_kernel (bprm->interp, bprm);if (retval <0 )
@@ -231,6 +228,8 @@ static int load_misc_binary(struct linux goto ret; bprm->interpreter = interp_file; +if (fmt->flags &MISC_FMT_OPEN_BINARY ) + bprm->have_execfd =1 ;if (fmt->flags &MISC_FMT_CREDENTIALS ) bprm->execfd_creds =1 ;
Greg Kroah-Hartman
maintainerPATCH 231/609 platform/loongarch: laptop: Explicitly reset bl_powered state when suspend
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zixing Liu <[email protected]>
commit 91a70492c03040d51b36f595530d6491d5d6c541 upstream.
On EAECIS NL60R with EC firmware version 1.11, resuming from S3 has a very high chance (>90%) of causing the EC to lose the previous backlight power state. When this happens, the laptop resumes normally from S3, but the backlight remains off (when shining on the screen with a flash light, we can see the screen contents are updating normally).
Since there is no generic way to query the EC's backlight state on Loongson laptop platforms, assume the worst-case scenario and restart the backlight power inside the kernel each time the system resumes.
--- drivers/platform/loongarch/loongson-laptop.c | 1 + 1 file changed, 1 insertion(+)
drivers/platform/loongarch/loongson-laptop.c +1 -0
@@ -189,6 +189,7 @@ static int __init setup_acpi_notify(strustatic int loongson_hotkey_suspend (struct device *dev) { + bl_powered = false;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 232/609 cdrom: fix stack out-of-bounds read in CDROMVOLCTRL
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xu Rao <[email protected]>
commit b27e195d4db8dea263050bdbeb11881b2999c9c6 upstream.
mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again.
For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged.
With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer.
This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure.
Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.
--- drivers/cdrom/cdrom.c | 1 + 1 file changed, 1 insertion(+)
drivers/cdrom/cdrom.c +1 -0
@@ -3205,6 +3205,7 @@ static noinline int mmc_ioctl_cdrom_volu/* set volume */ cgc->buffer = buffer + offset -8 ; + cgc->buflen -= offset -8 ;memset (cgc->buffer,0 ,8 );return cdrom_mode_select (cdi, cgc); }
Greg Kroah-Hartman
maintainerPATCH 233/609 x86/boot/compressed: Disable jump tables
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 4a9ec5ec9555ad62dc5b81a37ac946025c2ea002 upstream.
After a recent upstream LLVM change to start generating jump and lookup tables in switch statements in more instances [1], linking the compressed x86 boot image when CONFIG_KERNEL_ZSTD is enabled fails with:
ld.lld: error: Unexpected run-time relocations (.rela) detected!
Dumping the relocations in misc.o, which is the only file influenced by CONFIG_KERNEL_ZSTD in the decompressor, shows dynamic relocations to some string constants, which correspond to the string literals in the switch statement in handle_zstd_error():
Relocation section '.rela.data.rel.ro' at offset 0x277b0 contains 31 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 73a 0000000000000008 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e 0000000000000010 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e 0000000000000018 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e
...
This optimization is problematic for the decompressor environment, as it is built as -fPIE without any explicit absolute references (as described at the top of misc.c) while not applying any dynamic relocations, hence the linker assertion. To opt out of this optimization, which is of little value in this special early boot code, and to mirror the other x86 startup code in arch/x86/boot/startup, disable jump tables in the decompressor.
--- arch/x86/boot/compressed/Makefile | 1 + 1 file changed, 1 insertion(+)
arch/x86/boot/compressed/Makefile +1 -0
@@ -36,6 +36,7 @@ targets := vmlinux vmlinux.bin vmlinux.b KBUILD_CFLAGS := -m$(BITS) -O2 $(CLANG_FLAGS) KBUILD_CFLAGS += -std=gnu11 KBUILD_CFLAGS += -fno-strict-aliasing -fPIE +KBUILD_CFLAGS += -fno-jump-tables KBUILD_CFLAGS += -Wundef KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING cflags-$(CONFIG_X86_32) := -march=i386
Greg Kroah-Hartman
maintainerPATCH 234/609 comedi: comedi_parport: deal with premature interrupt
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Abbott <[email protected]>
commit 17221216ae8ce6a24e8a4e787382e3ebc81b88a8 upstream.
Syzbot reported a general protection fault in comedi_get_is_subdevice_running(), which was called from the interrupt handler parport_interrupt() in the "comedi_parport" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons:
1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first.
2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware.
Change the initialization order in the driver's comedi "attach" handler (parport_attach()) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware.
Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.
--- drivers/comedi/drivers/comedi_parport.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
drivers/comedi/drivers/comedi_parport.c +10 -3
@@ -211,6 +211,13 @@ static irqreturn_t parport_interrupt(intunsigned int ctrl;unsigned short val =0 ; +/* +* Check device is fully attached. Device interrupts should have +* been disabled, but do this in case of bad hardware. +*/ +if (!dev->attached) +return IRQ_NONE ; + ctrl =inb (dev->iobase +PARPORT_CTRL_REG );if (!(ctrl &PARPORT_CTRL_IRQ_ENA ))return IRQ_NONE ;
@@ -231,6 +238,9 @@ static int parport_attach(struct comedi_if (ret)return ret; +outb (0 , dev->iobase +PARPORT_DATA_REG ); +outb (0 , dev->iobase +PARPORT_CTRL_REG ); +if (it->options[1 ]) { ret =request_irq (it->options[1 ], parport_interrupt,0 , dev->board_name, dev);
@@ -286,9 +296,6 @@ static int parport_attach(struct comedi_ s->cancel = parport_intr_cancel; } -outb (0 , dev->iobase +PARPORT_DATA_REG ); -outb (0 , dev->iobase +PARPORT_CTRL_REG ); -return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 235/609 serial: sc16is7xx: implement gpio get_direction() callback
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hugo Villeneuve <[email protected]>
commit af071d9e07e57cfff239e8d09d2f3b05ebc9c667 upstream.
It's strongly recommended for GPIO drivers to always implement the .get_direction() callback - even when the direction is tracked in software. The GPIO core emits a warning when the callback is missing and a user reads the direction of a line, e.g. via /sys/kernel/debug/gpio.
--- drivers/tty/serial/sc16is7xx.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/tty/serial/sc16is7xx.c +12 -0
@@ -1311,6 +1311,17 @@ static void sc16is7xx_gpio_set(struct gp val ? BIT(offset) : 0); } +static int sc16is7xx_gpio_get_direction (struct gpio_chip *chip,unsigned int offset) +{ +struct sc16is7xx_port *s =gpiochip_get_data (chip); +struct uart_port *port = &s->p[0 ].port; +unsigned int val; + + val =sc16is7xx_port_read (port,SC16IS7XX_IODIR_REG ); + +return val &BIT (offset) ?GPIO_LINE_DIRECTION_OUT :GPIO_LINE_DIRECTION_IN ; +} +static int sc16is7xx_gpio_direction_input (struct gpio_chip *chip,unsigned offset) {
@@ -1388,6 +1399,7 @@ static int sc16is7xx_setup_gpio_chip(str s->gpio.parent = dev; s->gpio.label =dev_name (dev); s->gpio.init_valid_mask = sc16is7xx_gpio_init_valid_mask; + s->gpio.get_direction = sc16is7xx_gpio_get_direction; s->gpio.direction_input = sc16is7xx_gpio_direction_input; s->gpio.get = sc16is7xx_gpio_get; s->gpio.direction_output = sc16is7xx_gpio_direction_output;
Greg Kroah-Hartman
maintainerPATCH 236/609 serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiangshan Yi <[email protected]>
commit 7fb13fd7e9a59a37cd911efff83abe19e3ee029d upstream.
Commit b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform.
Fix this by adding the missing NULL checks before calling the setup and exit callbacks.
--- drivers/tty/serial/8250/8250_mid.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
drivers/tty/serial/8250/8250_mid.c +9 -5
@@ -318,9 +318,11 @@ static int mid8250_probe(struct pci_devif (!uart.port.membase)return -ENOMEM ; - ret = mid->board->setup (mid, &uart.port); -if (ret) -return ret; +if (mid->board->setup) { + ret = mid->board->setup (mid, &uart.port); +if (ret) +return ret; + } ret =mid8250_dma_setup (mid, &uart);if (ret)
@@ -336,7 +338,8 @@ static int mid8250_probe(struct pci_devreturn 0 ; err: - mid->board->exit (mid); +if (mid->board->exit) + mid->board->exit (mid);return ret; }
@@ -346,7 +349,8 @@ static void mid8250_remove(struct pci_deserial8250_unregister_port (mid->line); - mid->board->exit (mid); +if (mid->board->exit) + mid->board->exit (mid); }static const struct mid8250_board pnw_board = {
Greg Kroah-Hartman
maintainerPATCH 237/609 intel_th: fix MSC output device reference leak
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guangshuo Li <[email protected]>
commit 761b785a0cfbce43761227bc42a7f984f31f8921 upstream.
intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use.
commit 95fc36a234da ("intel_th: fix device leak on output open()") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead.
For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference.
Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.
--- drivers/hwtracing/intel_th/core.c | 10 ---------- drivers/hwtracing/intel_th/msu.c | 2 ++ 2 files changed, 2 insertions(+), 10 deletions(-)
drivers/hwtracing/intel_th/core.c +0 -10
@@ -843,18 +843,8 @@ out_put_device:return err; } -static int intel_th_output_release (struct inode *inode,struct file *file) -{ -struct intel_th_device *thdev = file->private_data; - -put_device (&thdev->dev); - -return 0 ; -} -static const struct file_operations intel_th_output_fops = { .open = intel_th_output_open, - .release = intel_th_output_release, .llseek = noop_llseek, };
drivers/hwtracing/intel_th/msu.c +2 -0
@@ -1477,8 +1477,10 @@ static int intel_th_msc_release(struct i {struct msc_iter *iter = file->private_data;struct msc *msc = iter->msc; +struct intel_th_device *thdev = msc->thdev;msc_iter_remove (iter, msc); +put_device (&thdev->dev);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 238/609 tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit 144f29e85702234b23d2a62abf723e6a17eb5427 upstream.
If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists.
Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.
--- kernel/trace/trace_mmiotrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/trace_mmiotrace.c +1 -1
@@ -146,7 +146,7 @@ static ssize_t mmio_read(struct trace_it goto print_out; } -if (!hiter) +if (!hiter || !hiter->dev)return 0 ;mmio_print_pcidev (s, hiter->dev);
Greg Kroah-Hartman
maintainerPATCH 239/609 tracing: Fix resource leak on mmiotrace trace_pipe close
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: deepakraog <[email protected]>
commit c1d87e724ae55e781b7cc7ccafb34d9e668582b2 upstream.
The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated.
mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback.
tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference.
Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler.
Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run:
# head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824
Over and over again, it would trigger a massive leak.
--- kernel/trace/trace_mmiotrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/trace_mmiotrace.c +1 -1
@@ -109,7 +109,6 @@ static void mmio_pipe_open(struct trace_ iter->private = hiter; } -/* XXX: This is not called when the pipe is closed! */ static void mmio_close (struct trace_iterator *iter) {struct header_iter *hiter = iter->private;
@@ -279,6 +278,7 @@ static struct tracer mmio_tracer __read_ .start = mmio_trace_start, .pipe_open = mmio_pipe_open, .close = mmio_close, + .pipe_close = mmio_close, .read = mmio_read, .print_line = mmio_print_line, .noboot = true,
Greg Kroah-Hartman
maintainerPATCH 240/609 tracing/eprobe: Fix exact system name matching in eprobe_dyn_event_match()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masami Hiramatsu (Google) <[email protected]>
commit f418d68d71fd4a0a9cef92377bc8c4c3334b5b53 upstream.
eprobe_dyn_event_match() checks if the target event system in argv[0] matches ep->event_system using strncmp(ep->event_system, argv[0], len). However, if ep->event_system is longer than len (e.g. "eprobes" vs "ep/event"), strncmp() still returns 0 because the first len characters match.
Check that ep->event_system[len] is '\0' to ensure exact system name matching.
--- kernel/trace/trace_eprobe.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/trace/trace_eprobe.c +2 -1
@@ -164,7 +164,8 @@ static bool eprobe_dyn_event_match(constif (!slash)return false; -if (strncmp (ep->event_system, argv[0 ], slash - argv[0 ])) +if (strncmp (ep->event_system, argv[0 ], slash - argv[0 ]) || + ep->event_system[slash - argv[0 ]] !='\0' )return false;if (strcmp (ep->event_name, slash +1 ))return false;
Greg Kroah-Hartman
maintainerPATCH 241/609 tracing/probes: Avoid temporary buffer truncation in trace_probe_match_command_args()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masami Hiramatsu (Google) <[email protected]>
commit 15f197856d68882af9416fc97516bb55079b7677 upstream.
In trace_probe_match_command_args(), a stack buffer buf[MAX_ARGSTR_LEN + 1] (256 bytes) is used to format "<name>=<comm>". However, since name can be up to 32 bytes (MAX_ARG_NAME_LEN) and comm up to 255 bytes (MAX_ARGSTR_LEN), the formatted string can exceed 256 bytes and get truncated by snprintf(), causing spurious argument matching failures.
Instead of formatting into a temporary buffer on stack, compare the argument name, the '=' delimiter, and the comm expression directly.
--- kernel/trace/trace_probe.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
kernel/trace/trace_probe.c +5 -4
@@ -1215,16 +1215,17 @@ int trace_probe_compare_arg_type(structbool trace_probe_match_command_args (struct trace_probe *tp,int argc,const char **argv) { -char buf[MAX_ARGSTR_LEN +1 ];int i;if (tp->nr_args < argc)return false;for (i =0 ; i < argc; i++) { -snprintf (buf,sizeof (buf),"%s=%s" , - tp->args[i].name, tp->args[i].comm); -if (strcmp (buf, argv[i])) +int len =strlen (tp->args[i].name); + +if (strncmp (argv[i], tp->args[i].name, len) || + argv[i][len] !='=' || +strcmp (argv[i] + len +1 , tp->args[i].comm))return false; }return true;
Greg Kroah-Hartman
maintainerPATCH 242/609 tracing/probes: Fix potential underflow in LEN_OR_ZERO macro
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masami Hiramatsu (Google) <[email protected]>
commit 8ce20bfba48902e1382187cd1a852f7cf3a1e739 upstream.
In __set_print_fmt(), LEN_OR_ZERO is defined as (len ? len - pos : 0). If len is non-zero but smaller than pos, len - pos evaluates to a negative integer. When passed as a size argument to snprintf(), this negative value is cast to a large unsigned size_t, bypassing buffer size limits.
Ensure len > pos before subtracting to avoid integer underflow.
--- kernel/trace/trace_probe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/trace_probe.c +1 -1
@@ -900,7 +900,7 @@ int traceprobe_update_arg(struct probe_a }/* When len=0, we just calculate the needed length */ -#define LEN_OR_ZERO (len ? len - pos : 0) +#define LEN_OR_ZERO (len > pos ? len - pos : 0)static int __set_print_fmt (struct trace_probe *tp,char *buf,int len,enum probe_print_type ptype) {
Greg Kroah-Hartman
maintainerPATCH 243/609 tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masami Hiramatsu (Google) <[email protected]>
commit a9d6fb284039a5d3858a1d9f9a0d7e46cfb7c2d4 upstream.
If trace_probe_log.argc is 0 in __trace_probe_log_err(), the loop constructing the command string will not execute and p will remain equal to command. Writing to *(p - 1) will cause an out-of-bounds access before command. This should not happen, but better to be treated.
Reject if trace_probe_log.argc is 0.
--- kernel/trace/trace_probe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/trace_probe.c +1 -1
@@ -176,7 +176,7 @@ void __trace_probe_log_err(int offset, ilockdep_assert_held (&dyn_event_ops_mutex); -if (!trace_probe_log.argv) +if (!trace_probe_log.argv || !trace_probe_log.argc)return ;/* Recalculate the length and allocate buffer */
Greg Kroah-Hartman
maintainerPATCH 244/609 arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit e057b94772328221405b067c3a85fe479b915dc8 upstream.
When seccomp support was originally added to arm64 in a1ae65b21941 ("arm64: add seccomp support"), seccomp was erroneously called _before_ the ptrace syscall-enter-stop and therefore the tracer could trivially manipulate the syscall register state after the seccomp check had passed. This was subsequently fixed in a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") by moving the seccomp check after the tracer has run. Unfortunately, a decade later, that fix has been reported to be incomplete.
On arm64, both the first argument to a syscall and its eventual return value are allocated to register x0. In order to facilitate syscall restarting and querying of syscall arguments on the syscall exit path, the original value of x0 is stashed in 'struct pt_regs::orig_x0' early during the syscall entry path and is returned for the first argument by syscall_get_arguments(). Unlike 32-bit Arm, this stashed value is not directly exposed via ptrace() and so changes to register x0 made by the tracer on a syscall-enter-stop are not reflected in 'orig_x0'. This means that seccomp, syscall tracepoints and audit can observe a stale value for the register compared to the argument that will be observed by the actual syscall.
Re-sync 'orig_x0' from x0 on the syscall entry path following a potential ptrace stop (i.e. PTRACE_EVENTMSG_SYSCALL_ENTRY or SECCOMP_RET_TRACE). This behaviour is limited to native tasks (because compat tasks expose 'orig_r0' to ptrace) where the syscall is not being skipped (because x0 is updated to hold the return value of -ENOSYS in that case).
--- arch/arm64/kernel/ptrace.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
arch/arm64/kernel/ptrace.c +29 -0
@@ -2140,6 +2140,21 @@ static void report_syscall(struct pt_reg } } +static void update_syscall_orig_x0_after_ptrace (struct pt_regs *regs) +{ +/* +* Keep orig_x0 authoritative so that seccomp (via +* syscall_get_arguments()), audit and the restart path all see the same +* first argument the syscall is dispatched with, even if it has been +* updated by a tracer. Skip this for NO_SYSCALL (set either by the user +* or the tracer), as regs[0] holds the return value (see the comment in +* el0_svc_common()) and can be unwound using syscall_rollback(). +* For compat tasks, orig_r0 is provided directly through GPR index 17. +*/ +if (!is_compat_task () && regs->syscallno !=NO_SYSCALL ) + regs->orig_x0 = regs->regs[0 ]; +} +int syscall_trace_enter (struct pt_regs *regs) {unsigned long flags =read_thread_flags ();
@@ -2148,12 +2163,26 @@ int syscall_trace_enter(struct pt_regs *report_syscall (regs,PTRACE_SYSCALL_ENTER );if (flags & _TIF_SYSCALL_EMU)return NO_SYSCALL ; + +/* +* Ensure ptrace changes to x0 during a regular +* syscall-enter-stop (PTRACE_SYSCALL) are visible to +* subsequent seccomp checks, tracepoints and audit. +*/ +update_syscall_orig_x0_after_ptrace (regs); }/* Do the secure computing after ptrace; failures should be fast. */ if (secure_computing () ==-1 )return NO_SYSCALL ; +/* +* Ensure tracer changes to x0 during seccomp ptrace exit +* processing (SECCOMP_RET_TRACE) are visible to tracepoints and +* audit. +*/ +update_syscall_orig_x0_after_ptrace (regs); +if (test_thread_flag (TIF_SYSCALL_TRACEPOINT ))trace_sys_enter (regs, regs->syscallno);
Greg Kroah-Hartman
maintainerPATCH 245/609 Revert "arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates"
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit 26b483d52417253d88a3a01262ac85914a7aec8e upstream.
This reverts commit e057b94772328221405b067c3a85fe479b915dc8.
Sashiko points out that updating 'orig_x0' after secure_computing() has returned is too late to handle the case where a seccomp filter is re-evaluated after initially returning SECCOMP_RET_TRACE. This means that a tracer can manipulate the first argument of the syscall behind seccomp's back.
For now, revert the initial fix and we'll have another crack at it soon. Since the incorrect fix was cc'd to stable, do the same here with an appropriate fixes tag.
--- arch/arm64/kernel/ptrace.c | 29 ----------------------------- 1 file changed, 29 deletions(-)
arch/arm64/kernel/ptrace.c +0 -29
@@ -2140,21 +2140,6 @@ static void report_syscall(struct pt_reg } } -static void update_syscall_orig_x0_after_ptrace (struct pt_regs *regs) -{ -/* -* Keep orig_x0 authoritative so that seccomp (via -* syscall_get_arguments()), audit and the restart path all see the same -* first argument the syscall is dispatched with, even if it has been -* updated by a tracer. Skip this for NO_SYSCALL (set either by the user -* or the tracer), as regs[0] holds the return value (see the comment in -* el0_svc_common()) and can be unwound using syscall_rollback(). -* For compat tasks, orig_r0 is provided directly through GPR index 17. -*/ -if (!is_compat_task () && regs->syscallno !=NO_SYSCALL ) - regs->orig_x0 = regs->regs[0 ]; -} -int syscall_trace_enter (struct pt_regs *regs) {unsigned long flags =read_thread_flags ();
@@ -2163,26 +2148,12 @@ int syscall_trace_enter(struct pt_regs *report_syscall (regs,PTRACE_SYSCALL_ENTER );if (flags & _TIF_SYSCALL_EMU)return NO_SYSCALL ; - -/* -* Ensure ptrace changes to x0 during a regular -* syscall-enter-stop (PTRACE_SYSCALL) are visible to -* subsequent seccomp checks, tracepoints and audit. -*/ -update_syscall_orig_x0_after_ptrace (regs); }/* Do the secure computing after ptrace; failures should be fast. */ if (secure_computing () ==-1 )return NO_SYSCALL ; -/* -* Ensure tracer changes to x0 during seccomp ptrace exit -* processing (SECCOMP_RET_TRACE) are visible to tracepoints and -* audit. -*/ -update_syscall_orig_x0_after_ptrace (regs); -if (test_thread_flag (TIF_SYSCALL_TRACEPOINT ))trace_sys_enter (regs, regs->syscallno);
Greg Kroah-Hartman
maintainerPATCH 246/609 mptcp: decrement subflows counter on failed passive join
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chenguang Zhao <[email protected]>
commit f3ca0ee2cc308e33896536789cbc5f3a12ca7b30 upstream.
mptcp_pm_allow_new_subflow() increments extra_subflows before __mptcp_finish_join() on the passive MP_JOIN path.
In case of race conditions, the subflow is dropped without calling mptcp_close_ssk(), so the counter is not rolled back.
Call mptcp_pm_close_subflow() when the join completion fails to decrement the subflows counter.
--- net/mptcp/protocol.c | 1 + 1 file changed, 1 insertion(+)
net/mptcp/protocol.c +1 -0
@@ -3795,6 +3795,7 @@ bool mptcp_finish_join(struct sock *ssk)mptcp_data_unlock (parent);if (!ret) { +mptcp_pm_close_subflow (msk); err_prohibited: subflow->reset_reason =MPTCP_RST_EPROHIBIT ;return false;
Greg Kroah-Hartman
maintainerPATCH 247/609 mptcp: only set DATA_FIN when a mapping is present
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Bommarito <[email protected]>
commit b2ff91b752b0d85e8815e7f44fd85205c4268094 upstream.
mptcp_get_options() clears only the status group of struct mptcp_options_received; data_seq, subflow_seq and data_len are filled in by mptcp_parse_option() exclusively inside the DSS mapping block, which runs only when the DSS M (mapping present) bit is set.
A peer can send a DSS option with the DATA_FIN flag set but the mapping bit clear. The parser then records mp_opt->data_fin while leaving data_len and data_seq uninitialized. For a zero-length segment mptcp_incoming_options() evaluates
if (mp_opt.data_fin && mp_opt.data_len == 1 && mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64))
which reads the uninitialized data_len and data_seq; KMSAN reports an uninit-value in mptcp_incoming_options(). The stale data_seq can also be fed into the receive-side DATA_FIN sequence tracking.
Record the DATA_FIN flag only when the DSS option carries a mapping, so data_fin is never set without data_seq and data_len also being present. data_fin is part of the status group that mptcp_get_options() clears up front, so on the no-map path it stays zero and the zero-length DATA_FIN branch is simply skipped. A DATA_FIN is always transmitted together with a mapping (mptcp_write_data_fin() sets use_map along with data_seq and data_len), so legitimate DATA_FIN handling is unaffected.
Move the pr_debug() that logs the parsed DSS flags below the mapping block, so it reports the final data_fin value instead of the stale one it would otherwise print before the assignment.
--- net/mptcp/options.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
net/mptcp/options.c +6 -6
@@ -152,17 +152,11 @@ static void mptcp_parse_option(const str ptr++; flags = (*ptr++) &MPTCP_DSS_FLAG_MASK ; - mp_opt->data_fin = (flags &MPTCP_DSS_DATA_FIN ) !=0 ; mp_opt->dsn64 = (flags &MPTCP_DSS_DSN64 ) !=0 ; mp_opt->use_map = (flags &MPTCP_DSS_HAS_MAP ) !=0 ; mp_opt->ack64 = (flags &MPTCP_DSS_ACK64 ) !=0 ; mp_opt->use_ack = (flags &MPTCP_DSS_HAS_ACK ); -pr_debug ("data_fin=%d dsn64=%d use_map=%d ack64=%d use_ack=%d\n" , - mp_opt->data_fin, mp_opt->dsn64, - mp_opt->use_map, mp_opt->ack64, - mp_opt->use_ack); - expected_opsize =TCPOLEN_MPTCP_DSS_BASE ;if (mp_opt->use_ack) {
@@ -173,12 +167,18 @@ static void mptcp_parse_option(const str }if (mp_opt->use_map) { + mp_opt->data_fin = (flags &MPTCP_DSS_DATA_FIN ) !=0 ;if (mp_opt->dsn64) expected_opsize +=TCPOLEN_MPTCP_DSS_MAP64 ;else expected_opsize +=TCPOLEN_MPTCP_DSS_MAP32 ; } +pr_debug ("data_fin=%d dsn64=%d use_map=%d ack64=%d use_ack=%d\n" , + mp_opt->data_fin, mp_opt->dsn64, + mp_opt->use_map, mp_opt->ack64, + mp_opt->use_ack); +/* Always parse any csum presence combination, we will enforce * RFC 8684 Section 3.3.0 checks later in subflow_data_ready */
Greg Kroah-Hartman
maintainerPATCH 248/609 sctp: dont free the ASCONFs own transport in DEL-IP processing
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jun Yang <[email protected]>
commit 9b2854f86f0b56e9027d68e7a3fc909d1a9b566f upstream.
sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address.
sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory.
Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.
--- net/sctp/sm_make_chunk.c | 6 ++++++ 1 file changed, 6 insertions(+)
net/sctp/sm_make_chunk.c +6 -0
@@ -3179,6 +3179,12 @@ static __be16 sctp_process_asconf_param(if (!peer)return SCTP_ERROR_DNS_FAILED ; +/* Don't free asconf->transport; a later wildcard DEL-IP +* parameter reuses it. +*/ +if (peer == asconf->transport) +return SCTP_ERROR_REQ_REFUSED ; +sctp_assoc_rm_peer (asoc, peer);break ;case SCTP_PARAM_SET_PRIMARY :
Greg Kroah-Hartman
maintainerPATCH 249/609 ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bryam Vargas <[email protected]>
commit 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02 upstream.
ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case:
snaptrace = h + 1;
snaptrace_len = le32_to_cpu(h->snap_trace_len);
p = snaptrace + snaptrace_len;
...
case CEPH_CAP_OP_IMPORT:
if (snaptrace_len) {
...
if (ceph_update_snap_trace(mdsc, snaptrace,
snaptrace + snaptrace_len,
false, &realm)) { ... }ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays.
The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced.
Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.
--- fs/ceph/caps.c | 1 + 1 file changed, 1 insertion(+)
fs/ceph/caps.c +1 -0
@@ -4117,6 +4117,7 @@ void ceph_handle_caps(struct ceph_mds_se snaptrace = h +1 ; snaptrace_len =le32_to_cpu (h->snap_trace_len); +ceph_decode_need (&snaptrace, end, snaptrace_len, bad); p = snaptrace + snaptrace_len;if (msg_version >=2 ) {
Greg Kroah-Hartman
maintainerPATCH 250/609 libceph: bound get_version reply decode to front len
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douya Le <[email protected]>
commit d3c32939fa0e3ee9b883b9a0fd1972c5c444e3d0 upstream.
handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received.
A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read.
Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.
--- net/ceph/mon_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ceph/mon_client.c +1 -1
@@ -821,7 +821,7 @@ static void handle_get_version_reply(strstruct ceph_mon_generic_request *req;u64 tid =le64_to_cpu (msg->hdr.tid);void *p = msg->front.iov_base; -void *end = p + msg->front_alloc_len; +void *const end = p + msg->front.iov_len;u64 handle;dout ("%s msg %p tid %llu\n" , __func__, msg, tid);
Greg Kroah-Hartman
maintainerPATCH 251/609 libceph: Fix multiplication overflow in decode_new_up_state_weight()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raphael Zimmer <[email protected]>
commit 98917a499ec7064c14fc56d180a4fd636fc2784c upstream.
If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part.
This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid.
[ idryomov: rename new_state_len -> new_state_item_size, formatting ]
--- net/ceph/osdmap.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/ceph/osdmap.c +4 -1
@@ -1844,6 +1844,8 @@ static int decode_new_up_state_weight(vovoid *new_up_client;void *new_state;void *new_weight_end; +const u32 new_state_item_size = +sizeof (u32) + (struct_v >=5 ?sizeof (u32) :sizeof (u8));u32 len;int ret;int i;
@@ -1864,7 +1866,8 @@ static int decode_new_up_state_weight(vo new_state = *p;ceph_decode_32_safe (p, end, len, e_inval); - len *=sizeof (u32) + (struct_v >=5 ?sizeof (u32) :sizeof (u8)); +if (check_mul_overflow (len, new_state_item_size, &len)) + goto e_inval;ceph_decode_need (p, end, len, e_inval); *p += len;
Greg Kroah-Hartman
maintainerPATCH 252/609 libceph: guard missing CRUSH type name lookup
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhao Zhang <[email protected]>
commit bbeae12fda3384a90fbebc8a19ba9d33f85b5361 upstream.
Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref.
Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to "not local".
[ idryomov: add WARN_ON_ONCE ]
--- net/ceph/osdmap.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/ceph/osdmap.c +4 -1
@@ -3060,8 +3060,11 @@ static int get_immediate_parent(struct cif (b->items[j] != id)continue ; - *parent_type_id = b->type; type_cn =lookup_crush_name (&c->type_names, b->type); +if (WARN_ON_ONCE (!type_cn)) +continue ; + + *parent_type_id = b->type; parent_loc->cl_type_name = type_cn->cn_name; parent_loc->cl_name = cn->cn_name;return b->id;
Greg Kroah-Hartman
maintainerPATCH 253/609 libceph: refresh auth->authorizer_buf{,_len} after authorizer update
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuangpeng Bai <[email protected]>
commit 937d61f86d377a3aa578adae7a3dfcecdddf9d89 upstream.
ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer.
ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory.
A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer.
Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.
--- net/ceph/auth_x.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
net/ceph/auth_x.c +8 -1
@@ -781,9 +781,16 @@ static int ceph_x_update_authorizer( au = (struct ceph_x_authorizer *)auth->authorizer;if (au->secret_id < th->secret_id) { +int ret; +dout ("ceph_x_update_authorizer service %u secret %llu < %llu\n" , au->service, au->secret_id, th->secret_id); -return ceph_x_build_authorizer (ac, th, au); + ret =ceph_x_build_authorizer (ac, th, au); +if (ret) +return ret; + + auth->authorizer_buf = au->buf->vec.iov_base; + auth->authorizer_buf_len = au->buf->vec.iov_len; }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 254/609 libceph: Reject monmaps advertising zero monitors
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raphael Zimmer <[email protected]>
commit 40480eee361ed9676b3f844d532ac28b47251634 upstream.
A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the "BUG_ON(monc->monmap->num_mon < 1)" assertion in pick_new_mon() is triggered.
This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON.
[ idryomov: drop "log output for unusual values of num_mon" part ]
--- net/ceph/mon_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ceph/mon_client.c +1 -1
@@ -114,7 +114,7 @@ static struct ceph_monmap *ceph_monmap_ddout ("%s fsid %pU epoch %u num_mon %u\n" , __func__, &fsid, epoch, num_mon); -if (num_mon >CEPH_MAX_MON ) +if (num_mon ==0 || num_mon >CEPH_MAX_MON ) goto e_inval; monmap =kmalloc (struct_size (monmap, mon_inst, num_mon),GFP_NOIO );
Greg Kroah-Hartman
maintainerPATCH 255/609 libceph: reject zero bucket types in crush_decode
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douya Le <[email protected]>
commit 05f90284223381005d6bcddab3fda4a97f9c3401 upstream.
CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices.
If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value.
Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.
--- net/ceph/osdmap.c | 2 ++ 1 file changed, 2 insertions(+)
net/ceph/osdmap.c +2 -0
@@ -520,6 +520,8 @@ static struct crush_map *crush_decode(voceph_decode_need (p, end,4 *sizeof (u32), bad); b->id =ceph_decode_32 (p); b->type =ceph_decode_16 (p); +if (b->type ==0 ) + goto bad; b->alg =ceph_decode_8 (p);if (b->alg != alg) { b->alg =0 ;
Greg Kroah-Hartman
maintainerPATCH 256/609 libceph: remove debugfs files before client teardown
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douya Le <[email protected]>
commit e4c804726c4afce3ba648b982d564f6af2cfa328 upstream.
ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free.
Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.
--- net/ceph/ceph_common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/ceph/ceph_common.c +2 -2
@@ -763,13 +763,13 @@ void ceph_destroy_client(struct ceph_cliatomic_set (&client->msgr.stopping,1 ); +ceph_debugfs_client_cleanup (client); +/* unmount */ ceph_osdc_stop (&client->osdc);ceph_monc_stop (&client->monc);ceph_messenger_fini (&client->msgr); -ceph_debugfs_client_cleanup (client); -ceph_destroy_options (client->options);kfree (client);
Greg Kroah-Hartman
maintainerPATCH 257/609 binfmt_elf_fdpic: only honour the first PT_INTERP
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit 3349ef6a366a61d631f6a263d12cea240957719d upstream.
The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs.
An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here.
The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 ("[PATCH] FRV: Add FDPIC ELF binary format driver").
--- fs/binfmt_elf_fdpic.c | 4 ++++ 1 file changed, 4 insertions(+)
fs/binfmt_elf_fdpic.c +4 -0
@@ -231,6 +231,10 @@ static int load_elf_fdpic_binary(structfor (i =0 ; i < exec_params.hdr.e_phnum; i++, phdr++) {switch (phdr->p_type) {case PT_INTERP : +/* elf ABI allows only one interpreter */ +if (interpreter_name) +continue ; + retval = -ENOMEM ;if (phdr->p_filesz >PATH_MAX ) goto error;
Greg Kroah-Hartman
maintainerPATCH 258/609 fscrypt: Add missing superblock check in find_or_insert_direct_key()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit b5fa40226e71c17847b9ff2816c6ca4133d0d994 upstream.
The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys).
The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted.
However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later.
Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs.
Note that this problem doesn't exist in the v2 policy equivalent ("per-mode keys"), since the data structures there are per super_block.
--- fs/crypto/keysetup_v1.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
fs/crypto/keysetup_v1.c +7 -1
@@ -199,13 +199,19 @@ find_or_insert_direct_key(struct fscryptif (memcmp (ci->ci_policy.v1.master_key_descriptor, dk->dk_descriptor,FSCRYPT_KEY_DESCRIPTOR_SIZE ) !=0 )continue ; +/* The sb is used at eviction time, so it must be the same. */ +if (ci->ci_inode->i_sb != dk->dk_sb) +continue ;if (ci->ci_mode != dk->dk_mode)continue ;if (!fscrypt_is_key_prepared (&dk->dk_key, ci))continue ;if (crypto_memneq (raw_key, dk->dk_raw, ci->ci_mode->keysize))continue ; -/* using existing tfm with same (descriptor, mode, raw_key) */ +/* +* Use an existing prepared key with the same (descriptor, sb, +* mode, inlinecrypt, raw_key) combination. +*/ refcount_inc (&dk->dk_refcount);spin_unlock (&fscrypt_direct_keys_lock);free_direct_key (to_insert);
Greg Kroah-Hartman
maintainerPATCH 259/609 ftrace: Add global mutex to serialize trace_parser access
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tengda Wu <[email protected]>
commit 7720b63bcef3f54c7fe288774b720a227d54a306 upstream.
In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input.
The affected handler paths and their specific functions are:
- Open paths: ftrace_regex_open(), ftrace_graph_open()
- Write paths: ftrace_regex_write(), ftrace_graph_write()
- Release paths: ftrace_regex_release(), ftrace_graph_release()
If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior.
Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.
--- kernel/trace/ftrace.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
kernel/trace/ftrace.c +13 -0
@@ -1037,6 +1037,12 @@ struct ftrace_ops global_ops = { };/* +* parser_lock - Protects trace_parser state against concurrent operations. +* Held across trace_get_user() and subsequent buffer parsing to prevent races. +*/ +static DEFINE_MUTEX (parser_lock); + +/* * Used by the stack unwinder to know about dynamic ftrace trampolines. */ struct ftrace_ops *ftrace_ops_trampoline (unsigned long addr)
@@ -5077,6 +5083,8 @@ ftrace_regex_write(struct file *file, co/* iter->hash is a local copy, so we don't need regex_lock */ parser = &iter->parser; + +guard (mutex)(&parser_lock); read =trace_get_user (parser, ubuf, cnt, ppos); if (read >= 0 && trace_parser_loaded(parser) &&
@@ -6129,12 +6137,14 @@ int ftrace_regex_release(struct inode *i iter = file->private_data; parser = &iter->parser; +mutex_lock (&parser_lock);if (trace_parser_loaded (parser)) {int enable = !(iter->flags &FTRACE_ITER_NOTRACE );ftrace_process_regex (iter, parser->buffer, parser->idx, enable); } +mutex_unlock (&parser_lock);trace_parser_put (parser);
@@ -6452,10 +6462,12 @@ ftrace_graph_release(struct inode *inode parser = &fgd->parser; +mutex_lock (&parser_lock);if (trace_parser_loaded ((parser))) { ret =ftrace_graph_set_hash (fgd->new_hash, parser->buffer); } +mutex_unlock (&parser_lock);trace_parser_put (parser);
@@ -6575,6 +6587,7 @@ ftrace_graph_write(struct file *file, co parser = &fgd->parser; +guard (mutex)(&parser_lock); read =trace_get_user (parser, ubuf, cnt, ppos); if (read >= 0 && trace_parser_loaded(parser) &&
Greg Kroah-Hartman
maintainerPATCH 260/609 iommu/vt-d: Disallow SVA if page walk is not coherent
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu <[email protected]>
commit 780dfed688622ea01be3c9c2c55eec2207f05e04 upstream.
Hardware implementations report Scalable-Mode Page-walk Coherency Support via the SMPWCS field in the extended capability register. If the hardware does not support page-walk coherency, a clflush is required every time the page table entries (which are walked by the IOMMU hardware) are updated.
In the SVA case, page tables are managed by the CPU mm core, not by the IOMMU driver. Because the IOMMU driver has no way of knowing whether the CPU page table management code has ensured coherency via clflush, the driver must deny SVA if the hardware does not support coherent paging.
--- drivers/iommu/intel/svm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iommu/intel/svm.c +1 -1
@@ -153,7 +153,7 @@ int intel_svm_finish_prq(struct intel_iovoid intel_svm_check (struct intel_iommu *iommu) { -if (!pasid_supported (iommu)) +if (!pasid_supported (iommu) || !ecap_smpwc (iommu->ecap))return ; if (cpu_feature_enabled(X86_FEATURE_GBPAGES) &&
Greg Kroah-Hartman
maintainerPATCH 261/609 phonet: pep: fix use-after-free in pep_get_sb()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
commit 0f71f852a96af9685858ce59fda34ecbf85c283d upstream.
pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF.
Reproduced under KASAN:
BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0
Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.
--- net/phonet/pep.c | 2 ++ 1 file changed, 2 insertions(+)
net/phonet/pep.c +2 -0
@@ -55,6 +55,8 @@ static unsigned char *pep_get_sb(struct ph =skb_header_pointer (skb,0 ,2 , &h);if (ph ==NULL || ph->sb_len <2 || !pskb_may_pull (skb, ph->sb_len))return NULL ; +/* pskb_may_pull() may have reallocated the head; refetch ph. */ + ph =skb_header_pointer (skb,0 ,2 , &h); ph->sb_len -=2 ; *ptype = ph->sb_type; *plen = ph->sb_len;
Greg Kroah-Hartman
maintainerPATCH 262/609 vxlan: require CAP_NET_ADMIN in the device netns for changelink
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Doruk Tan Ozturk <[email protected]>
commit 3a61bd9637f3d929aa846e4eb3d98b48c26fcb0e upstream.
A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net.
vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here.
Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series.
Found by 0sec automated security-research tooling (https://0sec.ai).
--- drivers/net/vxlan/vxlan_core.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/vxlan/vxlan_core.c +3 -0
@@ -4249,6 +4249,9 @@ static int vxlan_changelink(struct net_dstruct vxlan_rdst *dst;int err; +if (!rtnl_dev_link_net_capable (dev, vxlan->net)) +return -EPERM ; + dst = &vxlan->default_dst; err =vxlan_nl2conf (tb, data, dev, &conf, true, extack);if (err)
Greg Kroah-Hartman
maintainerPATCH 263/609 net: slip: serialize receive against buffer reallocation
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sungmin Kang <[email protected]>
commit ee7f9bb9320add61f7b367d7e6cd55e3a3a4d65d upstream.
sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock.
An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed.
Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.
--- drivers/net/slip/slip.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/slip/slip.c +4 -0
@@ -693,6 +693,8 @@ static void slip_receive_buf(struct tty_if (!sl || sl->magic !=SLIP_MAGIC || !netif_running (sl->dev))return ; +spin_lock_bh (&sl->lock); +/* Read the characters out of the buffer */ while (count--) {if (fp && *fp++) {
@@ -708,6 +710,8 @@ static void slip_receive_buf(struct tty_#endif slip_unesc (sl, *cp++); } + +spin_unlock_bh (&sl->lock); }/************************************
Greg Kroah-Hartman
maintainerPATCH 264/609 geneve: require CAP_NET_ADMIN in the device netns for changelink
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Doruk Tan Ozturk <[email protected]>
commit 8efb8f8bbb353b8f2fdf4f37534c6d96c9f69e01 upstream.
A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net.
geneve_changelink() applies the new configuration against geneve->net:geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here.
Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series.
Found by 0sec automated security-research tooling (https://0sec.ai).
--- drivers/net/geneve.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/geneve.c +3 -0
@@ -1760,6 +1760,9 @@ static int geneve_changelink(struct net_struct geneve_config cfg;int err; +if (!rtnl_dev_link_net_capable (dev, geneve->net)) +return -EPERM ; +/* If the geneve device is configured for metadata (or externally * controlled, for example, OVS), then nothing can be changed. */
Greg Kroah-Hartman
maintainerPATCH 265/609 net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hidayath Khan <[email protected]>
commit 47a5116e56a6b6fe1e909f244e39cd0fc26ceee4 upstream.
afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL.
The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path.
iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference.
Only call iucv_sock_kill() when a child socket was successfully allocated.
--- net/iucv/af_iucv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/iucv/af_iucv.c +2 -1
@@ -1873,7 +1873,8 @@ static int afiucv_hs_callback_syn(structafiucv_swap_src_dest (skb); trans_hdr->flags =AF_IUCV_FLAG_SYN |AF_IUCV_FLAG_FIN ; err =dev_queue_xmit (skb); -iucv_sock_kill (nsk); +if (nsk) +iucv_sock_kill (nsk);bh_unlock_sock (sk); goto out; }
Greg Kroah-Hartman
maintainerPATCH 266/609 net/iucv: fix use-after-free of a severed iucv_path
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bryam Vargas <[email protected]>
commit be7cc4656eb1f54029610e82d1f0fdd3f9b5ec0a upstream.
af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path.
Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.
--- net/iucv/af_iucv.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
net/iucv/af_iucv.c +14 -0
@@ -334,6 +334,7 @@ static void iucv_sever_path(struct sockunsigned char user_data[16 ];struct iucv_sock *iucv =iucv_sk (sk);struct iucv_path *path = iucv->path; +struct sock_msg_q *p, *n;/* Whoever resets the path pointer, must sever and free it. */ if (xchg (&iucv->path,NULL )) {
@@ -345,6 +346,19 @@ static void iucv_sever_path(struct sock }else pr_iucv->path_sever (path,NULL );iucv_path_free (path); + +/* +* Message notifications queued on message_q still reference +* the now freed path; drop them, otherwise a later recvmsg() +* would pass the freed iucv_path to message_receive() via +* iucv_process_message_q(). +*/ +spin_lock_bh (&iucv->message_q.lock); +list_for_each_entry_safe (p, n, &iucv->message_q.list, list) { +list_del (&p->list); +kfree (p); + } +spin_unlock_bh (&iucv->message_q.lock); } }
Greg Kroah-Hartman
maintainerPATCH 267/609 net/x25: fix use-after-free in x25_kill_by_neigh()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Lee <[email protected]>
commit 5499e0602d2faafd42c580d25f615903c3fbe11b upstream.
x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped.
The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock.
Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid.
A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().
--- net/x25/af_x25.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
net/x25/af_x25.c +6 -2
@@ -1773,15 +1773,19 @@ void x25_kill_by_neigh(struct x25_neigh {struct sock *s; +again:write_lock_bh (&x25_list_lock);sk_for_each (s, &x25_list) {if (x25_sk (s)->neighbour == nb) { +sock_hold (s);write_unlock_bh (&x25_list_lock);lock_sock (s); -x25_disconnect (s,ENETUNREACH ,0 ,0 ); +if (x25_sk (s)->neighbour == nb) +x25_disconnect (s,ENETUNREACH ,0 ,0 );release_sock (s); -write_lock_bh (&x25_list_lock); +sock_put (s); + goto again; } }write_unlock_bh (&x25_list_lock);
Greg Kroah-Hartman
maintainerPATCH 268/609 net: hip04: fix RX buffer leak on build_skb failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fan Wu <[email protected]>
commit 14fa65d10f5696b063a7d8d26e8291ea84a2c6ed upstream.
When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources.
Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails.
This issue was found by an in-house static analysis tool.
--- drivers/net/ethernet/hisilicon/hip04_eth.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/net/ethernet/hisilicon/hip04_eth.c +8 -3
@@ -594,7 +594,11 @@ static int hip04_rx_poll(struct napi_str skb =build_skb (buf, priv->rx_buf_size);if (unlikely (!skb)) {net_dbg_ratelimited ("build_skb failed\n" ); - goto refill; +/* Retain the slot; return budget so NAPI retries this +* buffer. Refill would overwrite rx_buf[]/rx_phys[] +* and leak them. +*/ +return budget; } dma_unmap_single(priv->dev, priv->rx_phys[priv->rx_head],
@@ -622,14 +626,15 @@ static int hip04_rx_poll(struct napi_str rx++; } -refill: buf =netdev_alloc_frag (priv->rx_buf_size);if (!buf) goto done; phys =dma_map_single (priv->dev, buf,RX_BUF_SIZE ,DMA_FROM_DEVICE ); -if (dma_mapping_error (priv->dev, phys)) +if (dma_mapping_error (priv->dev, phys)) { +skb_free_frag (buf); goto done; + } priv->rx_buf[priv->rx_head] = buf; priv->rx_phys[priv->rx_head] = phys;hip04_set_recv_desc (priv, phys);
Greg Kroah-Hartman
maintainerPATCH 269/609 proc: Fix broken error paths for namespace links
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit 425224c2d700391729be7fe6929a88ef4e2d7a4e upstream.
Don't return the return value of down_read_killable() (0) when a ptrace access check fails, return -EACCES as intended.
--- fs/proc/namespaces.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/proc/namespaces.c +3 -1
@@ -46,7 +46,7 @@ static const char *proc_ns_get_link(struconst struct proc_ns_operations *ns_ops =PROC_I (inode)->ns_ops;struct task_struct *task;struct path ns_path; -int error = -EACCES ; +int error;if (!dentry)return ERR_PTR (-ECHILD );
@@ -59,6 +59,7 @@ static const char *proc_ns_get_link(struif (error) goto out_put_task; + error = -EACCES ;if (!ptrace_may_access (task,PTRACE_MODE_READ_FSCREDS )) goto out;
@@ -90,6 +91,7 @@ static int proc_ns_readlink(struct dentrif (res) goto out_put_task; + res = -EACCES ;if (ptrace_may_access (task,PTRACE_MODE_READ_FSCREDS )) { res =ns_get_name (name,sizeof (name), task, ns_ops);if (res >=0 )
Greg Kroah-Hartman
maintainerPATCH 270/609 rbd: Reset positive result codes to zero in object map update path
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raphael Zimmer <[email protected]>
commit a6c4250b81bd30beae94e1b7a4b26fa1193ad2e4 upstream.
In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers.
This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.
--- drivers/block/rbd.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/block/rbd.c +6 -1
@@ -1957,10 +1957,15 @@ static int rbd_object_map_update_finish(bool has_current_state;void *p; -if (osd_req->r_result) +if (osd_req->r_result <0 )return osd_req->r_result;/* +* Writes aren't allowed to return a data payload. +*/ +WARN_ON_ONCE (osd_req->r_result >0 ); + +/* * Nothing to do for a snapshot object map. */ if (osd_req->r_num_ops ==1 )
Greg Kroah-Hartman
maintainerPATCH 271/609 ksmbd: defer destroy_previous_session() until after NTLM authentication
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Montgomery <[email protected]>
commit c74801ee524f477c174a1899782b6c3b6918d407 upstream.
In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM.
Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.
--- fs/smb/server/smb2pdu.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
fs/smb/server/smb2pdu.c +4 -5
@@ -1491,11 +1491,6 @@ static int ntlm_authenticate(struct ksmbreturn -EPERM ; } -/* Check for previous session */ - prev_id =le64_to_cpu (req->PreviousSessionId); -if (prev_id && prev_id != sess->id) -destroy_previous_session (conn, user, prev_id); -if (sess->state ==SMB2_SESSION_VALID ) {/* * Reuse session if anonymous try to connect
@@ -1533,6 +1528,10 @@ static int ntlm_authenticate(struct ksmb } } + prev_id =le64_to_cpu (req->PreviousSessionId); +if (prev_id && prev_id != sess->id) +destroy_previous_session (conn, sess->user, prev_id); +/* * If session state is SMB2_SESSION_VALID, We can assume * that it is reauthentication. And the user/password
Greg Kroah-Hartman
maintainerPATCH 272/609 ice: use READ_ONCE() to access cached PHC time
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Temerkhanov <[email protected]>
commit 2915681b89f817677ab9f1166d95b595bc144f5f upstream.
ptp.cached_phc_time is a 64-bit value updated by a periodic work item on one CPU and read locklessly on another. On 32-bit or non-atomic architectures this can result in a torn read. Use READ_ONCE() to enforce a single atomic load.
--- drivers/net/ethernet/intel/ice/ice_ptp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/ice/ice_ptp.c +1 -1
@@ -595,7 +595,7 @@ static u64 ice_ptp_extend_40b_ts(structreturn 0 ; } -return ice_ptp_extend_32b_ts (pf->ptp.cached_phc_time, +return ice_ptp_extend_32b_ts (READ_ONCE (pf->ptp.cached_phc_time), (in_tstamp >>8 ) & mask); }
Greg Kroah-Hartman
maintainerPATCH 273/609 ila: reload IPv6 header after pskb_may_pull in checksum adjust
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Bommarito <[email protected]>
commit 92d3817649df2b0b6a008a686c8275c88d7ef594 upstream.
ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer.
Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists.
Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.
--- net/ipv6/ila/ila_common.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
net/ipv6/ila/ila_common.c +12 -0
@@ -84,6 +84,7 @@ static void ila_csum_adjust_transport(ststruct tcphdr *th = (struct tcphdr *) (skb_network_header (skb) + nhoff); + ip6h =ipv6_hdr (skb); diff =get_csum_diff (ip6h, p);inet_proto_csum_replace_by_diff (&th->check, skb, diff, true, true);
@@ -95,6 +96,7 @@ static void ila_csum_adjust_transport(st (skb_network_header (skb) + nhoff);if (uh->check || skb->ip_summed ==CHECKSUM_PARTIAL ) { + ip6h =ipv6_hdr (skb); diff =get_csum_diff (ip6h, p);inet_proto_csum_replace_by_diff (&uh->check, skb, diff, true, true);
@@ -109,6 +111,7 @@ static void ila_csum_adjust_transport(ststruct icmp6hdr *ih = (struct icmp6hdr *) (skb_network_header (skb) + nhoff); + ip6h =ipv6_hdr (skb); diff =get_csum_diff (ip6h, p);inet_proto_csum_replace_by_diff (&ih->icmp6_cksum, skb, diff, true, true);
@@ -126,6 +129,15 @@ void ila_update_ipv6_locator(struct sk_bswitch (p->csum_mode) {case ILA_CSUM_ADJUST_TRANSPORT :ila_csum_adjust_transport (skb, p); +/* +* ila_csum_adjust_transport() calls pskb_may_pull(), which can +* reallocate the skb head and leave ip6h (and the iaddr derived +* from it) dangling; reload both before the write below. The +* other csum modes do not pull, so their cached pointers stay +* valid. +*/ + ip6h =ipv6_hdr (skb); + iaddr =ila_a2i (&ip6h->daddr);break ;case ILA_CSUM_NEUTRAL_MAP :if (sir2ila) {
Greg Kroah-Hartman
maintainerPATCH 274/609 mac802154: llsec: reject frames shorter than the authentication tag
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Doruk Tan Ozturk <[email protected]>
commit fd3a3f28ed60c6af4b2a39933b151d6b27842c3b upstream.
llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as
assoclen += datalen - authlen;
where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame.
The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction.
Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.
--- net/mac802154/llsec.c | 5 +++++ 1 file changed, 5 insertions(+)
net/mac802154/llsec.c +5 -0
@@ -888,6 +888,11 @@ llsec_do_decrypt_auth(struct sk_buff *sk data =skb_mac_header (skb) + skb->mac_len; datalen =skb_tail_pointer (skb) - data; +if (datalen < authlen) { +kfree_sensitive (req); +return -EBADMSG ; + } +sg_init_one (&sg,skb_mac_header (skb), assoclen + datalen);if (!(hdr->sec.level &IEEE802154_SCF_SECLEVEL_ENC )) {
Greg Kroah-Hartman
maintainerPATCH 275/609 mctp: serial: handle zero-length frames to prevent rx buffer overflow
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Doruk Tan Ozturk <[email protected]>
commit 793b9b729f1e8de57be8c8daf1a9838be96cabed upstream.
The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only:
if (c > MCTP_SERIAL_FRAME_MTU) {
dev->rxstate = STATE_ERR;
} else {
dev->rxlen = c;
dev->rxpos = 0;
dev->rxstate = STATE_DATA;
...
}A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is tested:
dev->rxbuf[dev->rxpos] = c;
dev->rxpos++;
dev->rxstate = STATE_DATA;
if (dev->rxpos == dev->rxlen) {
dev->rxpos = 0;
dev->rxstate = STATE_TRAILER;
}With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded.
Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path.
Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur.
KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change):
UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open
v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so
the trailer/framing bytes are still consumed (Jeremy Kerr).
Found by 0sec automated security-research tooling (https://0sec.ai).
--- drivers/net/mctp/mctp-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/mctp/mctp-serial.c +1 -1
@@ -316,7 +316,7 @@ static void mctp_serial_push_header(stru }else { dev->rxlen = c; dev->rxpos =0 ; - dev->rxstate =STATE_DATA ; + dev->rxstate = c >0 ?STATE_DATA :STATE_TRAILER ; dev->rxfcs =crc_ccitt_byte (dev->rxfcs, c); }break ;
Greg Kroah-Hartman
maintainerPATCH 276/609 pppoe: reload header pointer after dev_hard_header()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Asim Viladi Oglu Manizada <[email protected]>
commit e9c238f6fe42fb1b4dba3a578277de32cb487937 upstream.
pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it.
This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head.
Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.
--- drivers/net/ppp/pppoe.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ppp/pppoe.c +1 -0
@@ -900,6 +900,7 @@ static int pppoe_sendmsg(struct socket *dev_hard_header (skb, dev,ETH_P_PPP_SES , po->pppoe_pa.remote,NULL , total_len); + ph =pppoe_hdr (skb);memcpy (ph, &hdr,sizeof (struct pppoe_hdr )); ph->length =htons (total_len);
Greg Kroah-Hartman
maintainerPATCH 277/609 tipc: clear sock->sk on the failed-insert path in tipc_sk_create()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daehyeon Ko <[email protected]>
commit ba0533fc163f905fe817cfabdf8ed4058da44800 upstream.
When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object:
if (tipc_sk_insert(tsk)) {
sk_free(sk);
pr_warn("Socket create failed; port number exhausted\n");
return -EINVAL;
}This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock.
tipc_release() already guards this exact "failed accept() releases a pre-allocated child" case with "if (sk == NULL) return 0;", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL.
Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided.
The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG.
BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)
--- net/tipc/socket.c | 1 + 1 file changed, 1 insertion(+)
net/tipc/socket.c +1 -0
@@ -503,6 +503,7 @@ static int tipc_sk_create(struct net *netipc_set_sk_state (sk,TIPC_OPEN );if (tipc_sk_insert (tsk)) {sk_free (sk); + sock->sk =NULL ;pr_warn ("Socket create failed; port number exhausted\n" );return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 278/609 drm/amd/pm: make pp_features read-only when scpm is enabled
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Wang <[email protected]>
commit 53c78ab388bfc1a4d72e756815d0db0a842c812e upstream.
SCPM owns power feature control when enabled.
Make pp_features read-only during sysfs setup by clearing its write bits and store callback.
--- drivers/gpu/drm/amd/pm/amdgpu_pm.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/gpu/drm/amd/pm/amdgpu_pm.c +5 -0
@@ -2004,6 +2004,11 @@ static int default_attr_update(struct am }else if (DEVICE_ATTR_IS (pp_features)) {if (adev->flags &AMD_IS_APU || gc_ver <IP_VERSION (9 ,0 ,0 )) *states =ATTR_STATE_UNSUPPORTED ; + +if (adev->scpm_enabled) { + dev_attr->attr.mode &= ~S_IWUGO ; + dev_attr->store =NULL ; + } }else if (DEVICE_ATTR_IS (gpu_metrics)) {if (gc_ver <IP_VERSION (9 ,1 ,0 )) *states =ATTR_STATE_UNSUPPORTED ;
Greg Kroah-Hartman
maintainerPATCH 279/609 drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit d06c4173a7c38c7a39e98859f839ce714c7af2c9 upstream.
There's no need to crash the kernel for these cases.
--- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +5 -8
@@ -3769,7 +3769,7 @@ static void gfx_v10_0_wait_reg_mem(struc WAIT_REG_MEM_ENGINE(eng_sel)));if (mem_space) -BUG_ON (addr0 &0x3 );/* Dword align */ +WARN_ON (addr0 &0x3 );/* Dword align */ amdgpu_ring_write (ring, addr0);amdgpu_ring_write (ring, addr1);amdgpu_ring_write (ring, ref);
@@ -8513,7 +8513,7 @@ static void gfx_v10_0_ring_emit_ib_gfx(s control |=0x400000 ;amdgpu_ring_write (ring, header); -BUG_ON (ib->gpu_addr &0x3 );/* Dword align */ +WARN_ON (ib->gpu_addr &0x3 );/* Dword align */ amdgpu_ring_write(ring, #ifdef __BIG_ENDIAN (2 << 0) |
@@ -8552,7 +8552,7 @@ static void gfx_v10_0_ring_emit_ib_compu }amdgpu_ring_write (ring,PACKET3 (PACKET3_INDIRECT_BUFFER ,2 )); -BUG_ON (ib->gpu_addr &0x3 );/* Dword align */ +WARN_ON (ib->gpu_addr &0x3 );/* Dword align */ amdgpu_ring_write(ring, #ifdef __BIG_ENDIAN (2 << 0) |
@@ -8585,9 +8585,9 @@ static void gfx_v10_0_ring_emit_fence(st* aligned if only send 32bit data low (discard data high) */ if (write64bit) -BUG_ON (addr &0x7 ); +WARN_ON (addr &0x7 );else -BUG_ON (addr &0x3 ); +WARN_ON (addr &0x3 );amdgpu_ring_write (ring,lower_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (addr));amdgpu_ring_write (ring,lower_32_bits (seq));
@@ -8639,9 +8639,6 @@ static void gfx_v10_0_ring_emit_fence_ki {struct amdgpu_device *adev = ring->adev; -/* we only allocate 32bit for each seq wb address */ -BUG_ON (flags &AMDGPU_FENCE_FLAG_64BIT ); -/* write fence seq to the "addr" */ amdgpu_ring_write (ring,PACKET3 (PACKET3_WRITE_DATA ,3 )); amdgpu_ring_write(ring, (WRITE_DATA_ENGINE_SEL(0) |
Greg Kroah-Hartman
maintainerPATCH 280/609 drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 0eebcab1ea2a77f086a04108f386f82ee3496022 upstream.
There's no need to crash the kernel for these cases.
--- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c +5 -8
@@ -309,7 +309,7 @@ static void gfx_v11_0_wait_reg_mem(struc WAIT_REG_MEM_ENGINE(eng_sel)));if (mem_space) -BUG_ON (addr0 &0x3 );/* Dword align */ +WARN_ON (addr0 &0x3 );/* Dword align */ amdgpu_ring_write (ring, addr0);amdgpu_ring_write (ring, addr1);amdgpu_ring_write (ring, ref);
@@ -5400,7 +5400,7 @@ static void gfx_v11_0_ring_emit_ib_gfx(s control |=0x400000 ;amdgpu_ring_write (ring, header); -BUG_ON (ib->gpu_addr &0x3 );/* Dword align */ +WARN_ON (ib->gpu_addr &0x3 );/* Dword align */ amdgpu_ring_write(ring, #ifdef __BIG_ENDIAN (2 << 0) |
@@ -5439,7 +5439,7 @@ static void gfx_v11_0_ring_emit_ib_compu }amdgpu_ring_write (ring,PACKET3 (PACKET3_INDIRECT_BUFFER ,2 )); -BUG_ON (ib->gpu_addr &0x3 );/* Dword align */ +WARN_ON (ib->gpu_addr &0x3 );/* Dword align */ amdgpu_ring_write(ring, #ifdef __BIG_ENDIAN (2 << 0) |
@@ -5476,9 +5476,9 @@ static void gfx_v11_0_ring_emit_fence(st* aligned if only send 32bit data low (discard data high) */ if (write64bit) -BUG_ON (addr &0x7 ); +WARN_ON (addr &0x7 );else -BUG_ON (addr &0x3 ); +WARN_ON (addr &0x3 );amdgpu_ring_write (ring,lower_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (addr));amdgpu_ring_write (ring,lower_32_bits (seq));
@@ -5530,9 +5530,6 @@ static void gfx_v11_0_ring_emit_fence_ki {struct amdgpu_device *adev = ring->adev; -/* we only allocate 32bit for each seq wb address */ -BUG_ON (flags &AMDGPU_FENCE_FLAG_64BIT ); -/* write fence seq to the "addr" */ amdgpu_ring_write (ring,PACKET3 (PACKET3_WRITE_DATA ,3 )); amdgpu_ring_write(ring, (WRITE_DATA_ENGINE_SEL(0) |
Greg Kroah-Hartman
maintainerPATCH 281/609 drm/amdgpu/gfx8: drop unecessary BUG_ON()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 84a1a8a952ab4b8c23c5dd1f2eea4049cb4914f5 upstream.
There's no need to crash the kernel for this case.
--- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 --- 1 file changed, 3 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c +0 -3
@@ -6291,9 +6291,6 @@ static void gfx_v8_0_ring_emit_fence_comstatic void gfx_v8_0_ring_emit_fence_kiq (struct amdgpu_ring *ring,u64 addr,u64 seq,unsigned int flags) { -/* we only allocate 32bit for each seq wb address */ -BUG_ON (flags &AMDGPU_FENCE_FLAG_64BIT ); -/* write fence seq to the "addr" */ amdgpu_ring_write (ring,PACKET3 (PACKET3_WRITE_DATA ,3 )); amdgpu_ring_write(ring, (WRITE_DATA_ENGINE_SEL(0) |
Greg Kroah-Hartman
maintainerPATCH 282/609 drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 6302be10b521f5106ce01eb5a724b9e7945a5061 upstream.
There's no need to crash the kernel for these cases.
--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +5 -5
@@ -978,7 +978,7 @@ static void gfx_v9_0_wait_reg_mem(struct WAIT_REG_MEM_ENGINE(eng_sel)));if (mem_space) -BUG_ON (addr0 &0x3 );/* Dword align */ +WARN_ON (addr0 &0x3 );/* Dword align */ amdgpu_ring_write (ring, addr0);amdgpu_ring_write (ring, addr1);amdgpu_ring_write (ring, ref);
@@ -5178,7 +5178,7 @@ static void gfx_v9_0_ring_emit_ib_gfx(st }amdgpu_ring_write (ring, header); -BUG_ON (ib->gpu_addr &0x3 );/* Dword align */ +WARN_ON (ib->gpu_addr &0x3 );/* Dword align */ amdgpu_ring_write(ring, #ifdef __BIG_ENDIAN (2 << 0) |
@@ -5213,7 +5213,7 @@ static void gfx_v9_0_ring_emit_ib_comput }amdgpu_ring_write (ring,PACKET3 (PACKET3_INDIRECT_BUFFER ,2 )); -BUG_ON (ib->gpu_addr &0x3 );/* Dword align */ +WARN_ON (ib->gpu_addr &0x3 );/* Dword align */ amdgpu_ring_write(ring, #ifdef __BIG_ENDIAN (2 << 0) |
@@ -5247,9 +5247,9 @@ static void gfx_v9_0_ring_emit_fence(str* aligned if only send 32bit data low (discard data high) */ if (write64bit) -BUG_ON (addr &0x7 ); +WARN_ON (addr &0x7 );else -BUG_ON (addr &0x3 ); +WARN_ON (addr &0x3 );amdgpu_ring_write (ring,lower_32_bits (addr));amdgpu_ring_write (ring,upper_32_bits (addr));amdgpu_ring_write (ring,lower_32_bits (seq));
Greg Kroah-Hartman
maintainerPATCH 283/609 drm/amdgpu/vce: fix integer overflow in image size
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boyuan Zhang <[email protected]>
commit 186bfdc4e26d019b2e7570cb121964a1d89b2e5b upstream.
Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access.
The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware.
V2: remove redundant check
V3: modify max height value
V4: remove size64
--- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c +14 -3
@@ -856,9 +856,20 @@ int amdgpu_vce_ring_parse_cs(struct amdg goto out; } - *size =amdgpu_ib_get_value (ib, idx +8 ) * -amdgpu_ib_get_value (ib, idx +10 ) * -8 *3 /2 ; +uint32_t width, height; + width =amdgpu_ib_get_value (ib, idx +8 ); + height =amdgpu_ib_get_value (ib, idx +10 ); + +if (width ==0 || height ==0 || + width >4096 || height >2304 ) { +DRM_ERROR ("invalid VCE image size: %ux%u\n" , + width, height); + r = -EINVAL ; + goto out; + } + + *size = width * height *8 *3 /2 ; +break ;case 0x04000001 :/* config extension */