From nobody Thu Apr 2 09:32:32 2026 Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) (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 1B83F35DD09 for ; Mon, 2 Feb 2026 12:04:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=203.254.224.24 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770033873; cv=none; b=ffEB3qlUtxHNu8ilfj3RF6Efb8yPiC98+cuvw1aIJxIMBSKx7M0FP77K/fmt9AuabotsMy6PTQkQSdv/IrxgvIoMo+E6YphRORBPrTe0GE69tIo2adKPgfsxDay+wAQHBiFNR+uaEEG7/zZ53aiSEvE3zMZvoFhrixnXMd6FofA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770033873; c=relaxed/simple; bh=K+1M+tjOm8I30ri2kpWc1LrQdBc5qBFrUeFbxolUqq0=; h=Mime-Version:Subject:From:To:CC:Message-ID:Date:Content-Type: References; b=Y9wHH21Z45r+QabmVERDsviZrRGHQlQK6puMJ+k1HwHPcBhHnb2Wqux59dY0b9gF2nrZ01Jo4XcgXGF/8tzO017OjJpjVbs1qzcRzwP07l6Ytr4M/WexzleAsVmznQ4BDUZ3xhn8asZN864GAXbU8OpB/ayE4S8n0RiB0bfGGFM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com; spf=pass smtp.mailfrom=samsung.com; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b=BNMC6m8Q; arc=none smtp.client-ip=203.254.224.24 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=samsung.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="BNMC6m8Q" Received: from epcas2p3.samsung.com (unknown [182.195.41.55]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20260202120428epoutp01442b5e2d6159097ea7bae17c2a4e4635~QbGzLhwc32442424424epoutp01E for ; Mon, 2 Feb 2026 12:04:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20260202120428epoutp01442b5e2d6159097ea7bae17c2a4e4635~QbGzLhwc32442424424epoutp01E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1770033868; bh=K+1M+tjOm8I30ri2kpWc1LrQdBc5qBFrUeFbxolUqq0=; h=Subject:Reply-To:From:To:CC:Date:References:From; b=BNMC6m8Q1iP0yyuv8rF5xmQ8h4e9DNwpm9hSSHX0w/1NcQgzXIjoyzQcx4dn0Nkb0 4XnjzIO+VDipbe42R004iiZK7KX2Ts2Q0SRQVMV16muvxHQ6N/BKRV2rm86+0EySQt RCofpIzqlwIZV52GLK5v7lenY9Rcd6o6QXXISWms= Received: from epsnrtp04.localdomain (unknown [182.195.42.156]) by epcas2p4.samsung.com (KnoxPortal) with ESMTPS id 20260202120426epcas2p42899f3fdce022b1530a73d3e671d7406~QbGyAhCJw0524305243epcas2p4W; Mon, 2 Feb 2026 12:04:26 +0000 (GMT) Received: from epcas2p4.samsung.com (unknown [182.195.38.208]) by epsnrtp04.localdomain (Postfix) with ESMTP id 4f4QJp3gFyz6B9m5; Mon, 2 Feb 2026 12:04:26 +0000 (GMT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Subject: RE: Re: [Samsung] bsg-lib.c patch for double-free error fix. Reply-To: jonghwi.rha@samsung.com Sender: =?UTF-8?B?65287KKF7ZyY?= From: =?UTF-8?B?65287KKF7ZyY?= To: Jens Axboe CC: "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "hch@lst.de" , =?UTF-8?B?6rmA7KCV7YOc?= , =?UTF-8?B?7KCV7Zic7Jew?= X-Priority: 3 X-Content-Kind-Code: NORMAL X-CPGS-Detection: blocking_info_exchange X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20260202120425epcms2p481d034d2a8fc522819673f0bcd59cefd@epcms2p4> Date: Mon, 02 Feb 2026 21:04:25 +0900 X-CMS-MailID: 20260202120425epcms2p481d034d2a8fc522819673f0bcd59cefd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: AUTO_CONFIDENTIAL CMS-TYPE: 102P cpgsPolicy: CPGSC10-234,Y X-CFilter-Loop: Reflected X-CMS-RootMailID: 20260130091020epcms2p2d85af8781639a17ab517208feb270dbd References: Dear Jens, Sorry for the excuse, also thank you for the response.=C2=A0 It was my first time with the procedure, so there was a mistake. I apologiz= e for the inconvenience. As you mentioned, in the case of the previous patch, there was duplicate co= de, so changing it to kzalloc would indeed be meaningless. We have prepared a new patch and completed internal testing on our side.=C2= =A0Without this patch, issues occur when using ufs-bsg. Starting from Linux kernel version 5.x, advanced RPMB code was included to = the ufs-bsg path.=C2=A0In the advanced RPMB code path, the payload=E2=80=99= s sg_list is not used.=C2=A0 So, after other BSG operations, the previous value remains in payload.sg_li= st, which results in a double-free issue. Author: Jonghwi Rha Date:=C2=A0 =C2=A0Tue Jan 13 14:42:39 2026 +0900 =C2=A0 =C2=A0 bsg: initialize request and reply payloads in bsg_prepare_job =C2=A0 =C2=A0 struct bsg_job payloads contain fields that are only populate= d by =C2=A0 =C2=A0 certain commands, such as sg_list pointers. =C2=A0 =C2=A0 Because struct bsg_job is allocated with kmalloc(), memory ma= y be =C2=A0 =C2=A0 reused across requests. If a command does not populate all pa= yload =C2=A0 =C2=A0 fields, stale state from a previous job may remain and later = be =C2=A0 =C2=A0 misinterpreted during cleanup, potentially leading to use-aft= er-free =C2=A0 =C2=A0 or double-free issues. =C2=A0 =C2=A0 Initialize both request and reply payloads at the beginning o= f job =C2=A0 =C2=A0 preparation to ensure a clean state for all commands. =C2=A0 =C2=A0 Signed-off-by: Jonghwi Rha diff --git a/block/bsg-lib.c b/block/bsg-lib.c index 32da4a4429ce..0fbf8e311c03 100644 --- a/block/bsg-lib.c +++ b/block/bsg-lib.c @@ -234,6 +234,12 @@ static bool bsg_prepare_job(struct device *dev, struct= request *req) =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct bsg_job *job =3D blk_mq_rq_to_pdu(req); =C2=A0 =C2=A0 =C2=A0 =C2=A0 int ret; +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Clear stale SG state since bsg_job is reused= as a request PDU */ +=C2=A0 =C2=A0 =C2=A0 =C2=A0job->request_payload.sg_list =3D NULL; +=C2=A0 =C2=A0 =C2=A0 =C2=A0job->request_payload.sg_cnt =3D 0; +=C2=A0 =C2=A0 =C2=A0 =C2=A0job->reply_payload.sg_list =3D NULL; +=C2=A0 =C2=A0 =C2=A0 =C2=A0job->reply_payload.sg_cnt =3D 0; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 job->timeout =3D req->timeout; =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (req->bio) { P.S. Change-Id was for our gerrit system. Plz ignore it. Regards, Jonghwi, ---------Original Message--------- Sender: Jens Axboe Date: 2026-01-13 00:36 (GMT+09:00) Title: Re: [Samsung] bsg-lib.c patch for double-free error fix. =C2=A0 Please don't send patches as attachments, and particularly with html emails as they will just get dropped from the list. And it makes it impossible to reply to as well, as you then need to save and read the patch separately and import it into an email... > Change-Id: Iadb96f8736f8d9d9aae7b4a831c2a286ff59c520 What is this? diff --git a/block/bsg-lib.c b/block/bsg-lib.c index 9ceb5d0832f5..635b3b988f92 100644 --- a/block/bsg-lib.c +++ b/block/bsg-lib.c @@ -215,7 +215,7 @@ static int bsg_map_buffer(struct bsg_buffer *buf, struc= t request *req) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BUG_ON(!req->nr_phys_segments); - =C2=A0 =C2=A0 =C2=A0 =C2=A0buf->sg_list =3D kmalloc(sz, GFP_KERNEL); + =C2=A0 =C2=A0 =C2=A0 =C2=A0buf->sg_list =3D kzalloc(sz, GFP_KERNEL); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!buf->sg_list) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -ENOME= M; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sg_init_table(buf->sg_list, req->nr_phys_= segments); How does this make a difference, when sg_init_table() explicitly sets it all to 0? -- Jens Axboe