[PATCH mptcp-net] mptcp: pm: fix potential NULL deref in mptcp_pm_ops_init

[Gang Yan <gang.yan@linux.dev>]

From: Gang Yan <yangang@kylinos.cn>

mptcp_pm_find will return NULL when the PM is not registered. In that
case, mptcp_pm_ops_init will make it fallback to kernel_pm, and the
pr_warn_once will dereferences pm_ops->name.

This patch uses 'UNKNOWN' in pr_war_once to avoid this issue when the
pm_ops is NULL.

Signed-off-by: Gang Yan <yangang@kylinos.cn>
---

Notes:
    Hi Matt, Geliang
    
    This patch fixes a potential issue that might be encountered by the
    future eBPF path manager. However, as far as I know, this issue should
    not be triggered in the current codebase.
    
    That said, it could potentially be triggered in the future when the BPF
    Path Manager is in use. For example, in our current self-test
    environment, within a network namespace, we use a BPF-type path manager
    (specified via sysctl). If the path manager is unregistered and a new
    msk is created in that namespace, the code path would hit this and
    trigger a NULL pointer dereference.
    
    Therefore, I would suggest adding a simple check/handling here to make
    it more robust. WDYT?
    
    Thanks
    Gang

 net/mptcp/pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
index 9dc7b41fb562..0ba6dd25ba49 100644
--- a/net/mptcp/pm.c
+++ b/net/mptcp/pm.c
@@ -1142,7 +1142,7 @@ static void mptcp_pm_ops_init(struct mptcp_sock *msk,
 {
 	if (!pm_ops || !bpf_try_module_get(pm_ops, pm_ops->owner)) {
 		pr_warn_once("pm %s fails, fallback to default pm",
-			     pm_ops->name);
+			     pm_ops ? pm_ops->name : "UNKNOWN");
 		pm_ops = &mptcp_pm_kernel;
 	}
 
-- 
2.43.0