idev->mc_ifc_count can be overwritten without proper locking in
mld_process_v1.

This issue is similar to the one found in ipv6_mc_down / mld_ifc_work
(CVE-2024-26631), where mld_ifc_stop_work() modifies shared state without
holding idev->mc_lock.

mld_process_v1() invokes mld_gq_stop_work() and mld_ifc_stop_work()
to cancel MLDv2 report work and interface change work. However, unlike
other paths, it performs these calls without acquiring the mc_lock,
leading to potential data races if the work queue is running
concurrently.

Fix this by wrapping the calls to mld_gq_stop_work() and
mld_ifc_stop_work() with mutex_lock() and mutex_unlock() accordingly.

Signed-off-by: Kery Qi <qikeyu2017@gmail.com>
---
 net/ipv6/mcast.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 016b572e7d6f..6708eb693f9d 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1377,10 +1377,12 @@ static int mld_process_v1(struct inet6_dev *idev, struct mld_msg *mld,
 	if (v1_query)
 		mld_set_v1_mode(idev);
 
+	mutex_lock(&idev->mc_lock);
 	/* cancel MLDv2 report work */
 	mld_gq_stop_work(idev);
 	/* cancel the interface change work */
 	mld_ifc_stop_work(idev);
+	mutex_unlock(&idev->mc_lock);
 	/* clear deleted report items */
 	mld_clear_delrec(idev);
 
-- 
2.34.1