From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sipsolutions.net (s3.sipsolutions.net [168.119.38.16]) (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 EC76C32143D for ; Thu, 28 May 2026 07:13:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.38.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779952436; cv=none; b=GsBvqCVzpWcaNhwi5A35dyhChK3ZsNWDG+xyl3V9Bb7vyBuB9VlR+d+JRdY6AvESj7KngkBmXIFVUJ3ujWsbYpCsA92W8YDd8N38nKGch4D8CaaXoUKEHwwdT76QbdLGyB1dbLZ+6hPYTS1hfTTs4y9Zq2IvE6uJckvVQ5ioUn0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779952436; c=relaxed/simple; bh=cEfNXf5FA0/JfEy/uGLzghxeaR7x7407NCUyO6iJU7o=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=h8sMTAjT+Z9Ezst+zd3Ka2PNPH1+g6hLfyeG7DrOM2iDLgzEBp5eETA3QNyYnBZDe2kgJzTR/apjzrKAZHFca5YazqvaaEHnXiyO6OCtbLqVoa+2VEFxi9uWLAqOYqgfJXXJjdBdBhpNQECeh8cqYpZqjoNeLKp6lrdlhJUvTmk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=permerror header.from=sipsolutions.net; spf=none smtp.mailfrom=sipsolutions.net; dkim=pass (2048-bit key) header.d=sipsolutions.net header.i=@sipsolutions.net header.b=MXEqyxHP; arc=none smtp.client-ip=168.119.38.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=permerror header.from=sipsolutions.net Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=sipsolutions.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sipsolutions.net header.i=@sipsolutions.net header.b="MXEqyxHP" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=cEfNXf5FA0/JfEy/uGLzghxeaR7x7407NCUyO6iJU7o=; t=1779952434; x=1781162034; b=MXEqyxHPJC4fXgB0tMUKORmaeGvGIqx2PdolT5Um7aah2+g Gy/sw+Uoek/IGpvwUtFCK5IRmLIMC3ifH5RN4+LM2rpdJoCT4xJt45Yf1PbzgS2yGFboWY+o0btM+ 4DYWlVhrBcNrA2uFwhsKxBFy5M0x0wNNwDsrvEplzP5/tebXx7FKIP6LXfFYSER6bclTc2QFg+2fd KFkmxEGPMoVPEJtNibqJPYv58UStSzTSPmFwjEQBhLVD0XaCUgiQ2Nq+OLwIygKeGXE47eOnMy8mE SMzeYotpe1j1qQAcs2IRUv+kzDic4ZArD5hp5rixSiZY/MqSbcGQZN+K5nSX58Cw==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.98.2) (envelope-from ) id 1wSUw2-000000078lL-1xRY; Thu, 28 May 2026 09:13:42 +0200 Message-ID: Subject: Re: [PATCH] um: vector: avoid NULL queue dereference in legacy RX mode From: Johannes Berg To: Henry Barreto , Richard Weinberger , Anton Ivanov Cc: Tiwei Bie , linux-um@lists.infradead.org, linux-kernel@vger.kernel.org, Henry Barreto Date: Thu, 28 May 2026 09:13:37 +0200 In-Reply-To: <20260527213524.45903-1-contato@henrybarreto.dev> References: <20260527213524.45903-1-contato@henrybarreto.dev> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-malware-bazaar: not-scanned On Wed, 2026-05-27 at 18:35 -0300, Henry Barreto wrote: > From: Henry Barreto >=20 > Bringing a UML vector netdev up can panic in vector_net_open() with a > fault in _raw_spin_lock(). >=20 > vector_net_open() calls vector_reset_stats(), which takes the RX and TX > queue locks. However, queue allocation depends on runtime transport > options. With tap transport, vector RX/TX queues are not created and the > legacy header buffers are used instead. Taking a queue lock then > dereferences a NULL queue pointer. >=20 > Take the queue locks in vector_reset_stats() only when the corresponding > queue exists. Also move the RX queue lock in vector_poll() into the > VECTOR_RX path, so legacy RX does not touch rx_queue. >=20 > Fixes: 612a8c8e0b43 ("um: vector: Replace locks guarding queue depth with= atomics") So ... you're effectively saying that the tap transport has been broken since 6.12, released ~1.5 years ago. Maybe we should just remove that entirely since nobody complained? johannes