From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B51DD387370 for ; Wed, 14 Jan 2026 08:53:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768380815; cv=none; b=Vc0aSMBnvUj94HbdQmIaYDdw4sB4xP8Tn2VGnY9n/93dHtTgPdUQsmmMAl3C6pK8kC336kg2SGEJYJdOeBC+pZXJ6qP6kZlxPgNSDVS5i9QvB6bnUjDybEZTftNzsSlBNALzrWOizCMDTNsLrxjwlzM3hoe66C59vQu5AlbLtEw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768380815; c=relaxed/simple; bh=9ZxldlX5+QwAZglx8tOjhQAHuhmXu8tht81WJZBgDDg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZrU5F2jfMtSsUjXJspnlUU5cDpxHq36IEgRjo0BpezVWYW7fjONIjX070xUGDOORxNmc36Azo0U02EHI/aJTfu0Az1e0g4wimZ7hdtlacMgI0wRoEa4CJFKlzj1LP/Hvwo8/vh5I82c1my2j+dNBAqJrOuusj3yab0tCWjvQSeY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=B8V4WgH5; arc=none smtp.client-ip=91.218.175.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="B8V4WgH5" Message-ID: <1dc533ea-25ad-4c41-a7ff-14dfcfd3a261@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1768380809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xxIuouJO3MIKgvuqSxN9caUBLjtpXBt94bD24L3zHFA=; b=B8V4WgH5FMdeTFkhmyhej7cJLPT2N7WrmM4Y39ZqQtrM/NuPVQq1E7J4CE0oxMNTGEdu/K 9eClwT/leLZZco2JlMpbG/sAZ9glsp/dZ6XNPhd503d3BarxMDXsQSNufv4Ivw03kZUUxb rxMMtyNaJ83D/hLJLIbCjFIBRnuD7Lw= Date: Wed, 14 Jan 2026 16:53:20 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net-next] net/mlx5e: Mask wqe_id when handling rx cqe Content-Language: en-US To: Tariq Toukan , netdev@vger.kernel.org Cc: Saeed Mahameed , Tariq Toukan , Mark Bloch , Leon Romanovsky , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Oz Shlomo , Paul Blakey , Khalid Manaa , Achiad Shochat , Jiayuan Chen , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Leon Huang Fu References: <20260112080323.65456-1-leon.hwang@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Leon Hwang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 14/1/26 16:23, Tariq Toukan wrote: > > > On 12/01/2026 10:03, Leon Hwang wrote: >> The wqe_id from CQE contains wrap counter bits in addition to the WQE >> index. Mask it with sz_m1 to prevent out-of-bounds access to the >> rq->mpwqe.info[] array when wrap counter causes wqe_id to exceed RQ size. >> >> Without this fix, the driver crashes with NULL pointer dereference: >> >>    BUG: kernel NULL pointer dereference, address: 0000000000000020 >>    RIP: 0010:mlx5e_skb_from_cqe_mpwrq_linear+0xb3/0x280 [mlx5_core] >>    Call Trace: >>     >>     mlx5e_handle_rx_cqe_mpwrq+0xe3/0x290 [mlx5_core] >>     mlx5e_poll_rx_cq+0x97/0x820 [mlx5_core] >>     mlx5e_napi_poll+0x110/0x820 [mlx5_core] >> > > Hi, > > We do not expect out-of-bounds index, fixing it this way is not > necessarily correct. > > Can you please elaborate on your test case, setup, and how to repro? Hi, Thanks for the feedback. Unfortunately, we cannot reliably reproduce this issue on demand, as it was triggered on a production server. However, we preserved both the dmesg output and the coredump. >From analysis of the coredump, the wqe_id value was *4167*, which is unexpectedly out of bounds for the RQ size and led to the NULL pointer dereference shown above. For reference, here is the environment where the issue was observed: NIC: Mellanox Technologies MT2892 Family [ConnectX-6 Dx] Firmware: 22.43.2566 (MT_0000000359) OFED: MLNX_OFED 24.10-2.1.8 Kernel: 5.15.0-189.012-shopee (Ubuntu 24.04 based) Queue configuration: # ethtool -g enp23s0f0np0 RX: 4096 TX: 4096 # ethtool -l enp23s0f0np0 Combined: 20 Please let me know if additional details would be helpful. Thanks, Leon [...]