From 3ce5d47f2cc0b779b243b90a4594a26911bc41af Mon Sep 17 00:00:00 2001 From: Auke Kok Date: Wed, 15 Apr 2026 14:05:30 -0700 Subject: [PATCH 1/3] Initialize resp_data to silence clang uninitialized warning Clang flow analysis flags resp_data in process_response as possibly uninitialized when find_request returns NULL. kmod/src/net.c:533:6: error: variable 'resp_data' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] In practice the read is harmless because resp_func stays NULL in that path and call_resp_func only dereferences resp_data when resp_func is non-NULL. Initialize at declaration. Signed-off-by: Auke Kok --- kmod/src/net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kmod/src/net.c b/kmod/src/net.c index 8e7cdb4cf..f2bec7502 100644 --- a/kmod/src/net.c +++ b/kmod/src/net.c @@ -525,7 +525,7 @@ static int process_response(struct scoutfs_net_connection *conn, struct super_block *sb = conn->sb; struct message_send *msend; scoutfs_net_response_t resp_func = NULL; - void *resp_data; + void *resp_data = NULL; spin_lock(&conn->lock); From 347e27acecb22d261f5edad1f30afeafc1054345 Mon Sep 17 00:00:00 2001 From: Auke Kok Date: Wed, 15 Apr 2026 16:35:10 -0700 Subject: [PATCH 2/3] Fix leak in client side lock invalidation Clang's scan-build found this leak when we get an invalidation for a lock we no longer have. Free ireq to fix. Signed-off-by: Auke Kok --- kmod/src/lock.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kmod/src/lock.c b/kmod/src/lock.c index 63213874b..9b3eab613 100644 --- a/kmod/src/lock.c +++ b/kmod/src/lock.c @@ -813,6 +813,7 @@ int scoutfs_lock_invalidate_request(struct super_block *sb, u64 net_id, out: if (!lock) { + kfree(ireq); ret = scoutfs_client_lock_response(sb, net_id, nl); BUG_ON(ret); /* lock server doesn't fence timed out client requests */ } From 019125d86d5e16d43379082257856d940b37d400 Mon Sep 17 00:00:00 2001 From: Auke Kok Date: Wed, 15 Apr 2026 17:02:40 -0700 Subject: [PATCH 3/3] Don't swallow invalid message error A malformed message encountered here increases the counter, but doesn't tear down the connection because of the nested for loops. The comments indicate that that is the expected behavior - a misbehaving client should not be tolerated. Signed-off-by: Auke Kok --- kmod/src/net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kmod/src/net.c b/kmod/src/net.c index f2bec7502..b028d7c8e 100644 --- a/kmod/src/net.c +++ b/kmod/src/net.c @@ -804,7 +804,7 @@ static void scoutfs_net_recv_worker(struct work_struct *work) if (invalid_message(conn, nh)) { scoutfs_inc_counter(sb, net_recv_invalid_message); ret = -EBADMSG; - break; + goto out; } data_len = le16_to_cpu(nh->data_len);