From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D6E1E45BD7A for ; Fri, 22 May 2026 14:35:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779460530; cv=none; b=TVP7WRgXaCsEXz5WH7qLfmFpRLcscSErXFLOQ6DsbLkB5J6oTiiUt0AnJ4q4onsVv5W8Dlg2IocrVay+oQb6k5lgG9pZgpNPNBewofAXszAeea4CW4TCTh6CnRV0Xs3hVdFd/u5iloc7hYj2g12GBL2HWUwJjshxmvgeH5AIHB0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779460530; c=relaxed/simple; bh=0pZys+wSoBiXyitprUTSmHYjxXUAnEro2EUqhD9ujBA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=sqeK6kJ7zhg3ubdfzSxpmG7o7iUz7WSusFmnMq1ifDo7jM8gudhQLLbLIiEEsv1Dit80ozYIXRKenXNcz+bUgduNBgK3ZCr4p3U4I0cfpfvrONJDBf10akIWDL41P8Gq3QZuHbtdcZ/MD3tpKLs9TS2fZ7vWqCtBm55sVuJvC2E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=C5RMHl5p; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="C5RMHl5p" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2bc85eda6b6so36917315ad.1 for ; Fri, 22 May 2026 07:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779460527; x=1780065327; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=jKonkuXrYPfMqzp1yI15CcQn2/09bEE1ZzQIuyKgdNk=; b=C5RMHl5pzIPD5LgoIxP0yOiPl0Rq/hQjxNaXPgMkng3yzxTuN4p2gJGYnxhLJ0rZGL n4uHQsUFkbaiJnJCX3q2IaSqs4AQtQO8LC9HG3OPNdRZtFYKrb8I7JMRrma09jztRvo5 7BImYjwC/V0qZ3CiV6Zbb00gMTj51eP+woMOzk4pYeKXsq7S7qImvLbcvXcKDEo+WZ41 fwc6Egsvbj5NxdZRCti0IUwqUKLAo1M0GIs6Qah1x+E2RbqptESIjrS/7WUTGowuuikw A3InsNbPIjs/3O2NoHWKeeTEkRiNN4fl03uxUQdfH+bGNhVa5rk+9nRZf9txWoqNEr7y dWxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779460527; x=1780065327; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jKonkuXrYPfMqzp1yI15CcQn2/09bEE1ZzQIuyKgdNk=; b=n3elbJNENVuxbsROJq/LAUwKKjlY6RsBWG1swHSz2bzEdpO4bvur6MEHiAOKAYA7ag KSO91eoJRfJJKodWUFzdTVDlf8gpC8Wo2tgPvdN9IBM177NuA4ZBrHzv4aritsFvKa3q CYrCyqGqWmlYtINtkikSMeKcoxXU4eZoOuE2v4NQxeJn6nDBV5olm5yzs/YjmuYem+io 7/1YHUQqoaYGGpcrczVw+Di78WAOSJJLwsDSTpqWHpL4mXidgLi78mwjehWlSDg3BFt2 ZkgDR3RIO6kPrkkMyMsrlZrrK0pEmfKW1adIjx+PkvQDJmaW45vGwWW1cGbS8gwkp2ek 1RWg== X-Forwarded-Encrypted: i=1; AFNElJ+d+vIqZhZm5Z9Et48lapaEx7TKLlqtuTbviv9iMmKA94phC/4mq+/nhE5XpTqarvao5xivnfAd0podaQE=@vger.kernel.org X-Gm-Message-State: AOJu0YwlJrveSoPiuBR5E6rxQHjexEGrDf9M3EI70roYymygZA+a3p/a dK0oi1/2gStnLcn/s4EJ6IWk2wdIkLZSAuPiv+70D94aw/qGZqXQRm3FdeiqUg== X-Gm-Gg: Acq92OHG/bbSd/WzSv1r+Eb3E/v81Ju3Cu4sDPu/EWGVGc8feNCpTP7sDe3tY5AKALT EaL1yrL57EeSG84kkuqxJ6ZGPId/VqFwx6GEoy6gBNOpPj7J3TEVxHzPAq2KGEHJNhMtmDadgf9 WhMCtWaKtXkgAQENejoTTLax2AJYUzkIBjEejFIdjJo4aEVLFZ9wWEWy+rkDy2XJRH5Ew2dICq8 REIg6wLgaWvoupsyCHTSKykGa2Foqf7Q98Jeja1nHDSVYNQ9bnYVdDzB3QurfoKB4LpjBQms84z xbPPwnQn9QeC6S1tQCx3RuNaCrsFrDpFlSKwt/twAhflDDXlKs9Il8YbfYjZXd74CRY2mGYCQIg M4KzzuDxY1r16qc/2z+ZcPIjDV/BnTDVrrdkErEUHiagiqik5mGZsMYREZc71Y/cY/mJKRI2vD0 kfflR5xBgEP7HlpZJ6AQdBQdLvYSRscKkkSEe2Xj4mgNsuwyOopXKSgzSLCqM= X-Received: by 2002:a17:903:1a70:b0:2b9:ec37:2977 with SMTP id d9443c01a7336-2beb06bf9d7mr41912025ad.38.1779460526938; Fri, 22 May 2026 07:35:26 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2beb58b2cd6sm20600225ad.52.2026.05.22.07.35.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 07:35:26 -0700 (PDT) From: Maoyi Xie To: Nishanth Menon Cc: Siddharth Vadapalli , Roger Quadros , David Yang , Andrew Lunn , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: List iterator used after loop in netcp_register_{tx,rx}hook? Date: Fri, 22 May 2026 22:35:22 +0800 Message-Id: <20260522143522.83473-1-maoyixie.tju@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi all, I came across what looks like an iterator used after the loop ends in drivers/net/ethernet/ti/netcp_core.c (linux-7.1-rc1), in both netcp_register_txhook() and netcp_register_rxhook(). I would appreciate your input on whether this is worth fixing or whether I am misreading the pattern. list_for_each_entry(next, &netcp_priv->txhook_list_head, list) { if (next->order > order) break; } __list_add(&entry->list, next->list.prev, &next->list); When the loop walks the whole list without break (every existing hook has order <= the new one), `next` walks past the end of the list and `&next->list` aliases the list head via container_of() offset cancellation, so __list_add() resolves to inserting at the tail. That is the intended behaviour for the case where the loop falls through. The dereference of the iterator after the loop ends is the part I am unsure about. Same shape as the Koschel cleanups from 2022 (99d8ae4ec8a tracing, 2966a9918df clockevents, dc1acd5c946 dlm, and others) and the "controlled container confusion" pattern described in [1]. I drafted a candidate fix that initialises an explicit `insert_before` pointer to the list head and overwrites it to &next->list only on early break, then passes insert_before to __list_add(). The iterator is no longer dereferenced after the loop and the diff is 12+/4-, symmetric across tx and rx. I built netcp_core.o for ARM with keystone_defconfig at W=1 and the object compiles clean for our change. The W=1 warnings that remain are in netcp_ndo_open() at lines 1601-1662 (snprintf truncation) and are already present in the file, unrelated to this. I also ran a small userspace mock of the two versions across five scenarios: empty list, single entry above the new order, single entry below the new order, multiple entries with the new order in the middle, and multiple entries where the new order falls through to the tail. The final list ordering matches in every case. Does this look like something worth a [PATCH]? Happy to send one if so, or to drop it if the shape here is fine. Thanks, Maoyi https://maoyixie.com/ [1] Jakob Koschel et al., "UNCONTAINED: Uncovering Container Confusion in the Linux Kernel", USENIX Security 2023. https://www.usenix.org/conference/usenixsecurity23/presentation/koschel