From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 CD36D3246ED for ; Wed, 15 Apr 2026 21:48:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776289714; cv=none; b=fBcde9p4lG4FzoufI2+ePTzRqfeS3fts6ecrimLr4c91Rq5rTia44TE3lA1NKha6U1pVR9vWekcycQKxZ92mWmWDrqjm4Zc68ytN6Ve1EeyFC+pH9rmerr0y8rJC2bdPzsRjHLW0epB80vmOEJe3987EmJ4ctoi5Ub/TgyCUzAQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776289714; c=relaxed/simple; bh=HSbJ7b2GfHm7QF2U/lU2tID71YO60ldLPYeKB5OAhjs=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=oKP+3o/E9IsfVfUWqEY+byWPhyUUGkZKgPvc9KMBtvE3I7+s5nnVHMdk3thZDKDS8JkUGtxLX018gpERgwj0qa82wubBy+U0iqr6zqlcqL4WuxVXpQ0eLZ3BzURXb6agfWIHLP4TYPul4uH7pJiWxzbPQBWcHdfK4uD1/CigGSw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Ns6aOQSl; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=fR06KltO; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Ns6aOQSl"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="fR06KltO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776289711; 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=y5Yjy3S3BFKJDNyOmnU55JSd5lC7QzocCDrnIK6I4+k=; b=Ns6aOQSl8eAg7TVCe+v8kTEIvyqQQHYs+dKASjF67B53TzK8IT/ewOAFJQgcYeKMn30al/ +svggLAxsZ/wwuTm9rtm9K9XMltRZwkrd7HU1LDa7PFQE27o6dP3HsmSZqiMBKRM3t1AS3 PugoXRwhcYL9qR4cYU3xUIazMnfqJMU= Received: from mail-yw1-f198.google.com (mail-yw1-f198.google.com [209.85.128.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-626-j3mT4e-rPpqTPm8CVrh35Q-1; Wed, 15 Apr 2026 17:48:30 -0400 X-MC-Unique: j3mT4e-rPpqTPm8CVrh35Q-1 X-Mimecast-MFC-AGG-ID: j3mT4e-rPpqTPm8CVrh35Q_1776289710 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-79878791ec6so191360747b3.3 for ; Wed, 15 Apr 2026 14:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776289710; x=1776894510; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=y5Yjy3S3BFKJDNyOmnU55JSd5lC7QzocCDrnIK6I4+k=; b=fR06KltOwwZ9gzxVFCG8A9rQmORe/38800H4s1IIAJKlc+WWvoakTK1a0Ncn+Xj7XF BblmlIT6nOYqPsEPdKrL2D5GccHSXNLVZuu2QWJdLfdi5enCc94rAH1+0lx9EEWkOY41 UgDHX71EQIKGT7PZdJV8gnAOfHzjVdzDjeRqhvbI7n6VTReS/7WNQMlWq50KPVJ/Xl3q uLz7jNHptFdAiEuZCpTyqPA8pXiVF3w5CD/RsvaJMMTh9oVBnAjSI6g57SwhkC4qg953 CFwTeMThfZN5S6Ba3UY3uCYZ2QJOmypIJ+RDaLtOg03ZKKVOkteSFsflTd9LSWXs/tmC oIag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776289710; x=1776894510; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=y5Yjy3S3BFKJDNyOmnU55JSd5lC7QzocCDrnIK6I4+k=; b=L9W+yIRefcH3XwRgVciZk6dvNy9EFKSQsWnOaJoXv0t3BdysUazYtO991hvaApq2L8 sFPQKGO68TmKEyUccT/MiLF5yJgPK6ilTjtdNFk1bUEksclZSorSDsbzZHmoxFRgpHk1 PRkG46K+vSA7BkYDtOGUdVWYXnXQQegIJgjakdg0wC8Iv92l4nb6EfIZH36g/1FhNszl x3yVst0U5gBagsspLjbQbZNBFtJ1jAo0Zafe3r0POxgoGCtEXeKuuI6oLNaoDdW70dvB YRWdfJkiCmnV8PmGDBNY/RqZK7TVX+PT0Q3DxX5SP0bMpc3PM0nmzlsezcGUwsteu/Fz bopA== X-Forwarded-Encrypted: i=1; AFNElJ99Xyyfk7xaWkgxYqwRZT1K2DkQnu5sK4+ZifZOfhJMpsIqx9qKzwZCeldAznvMH3LPa4Vpg2AUxie02bs=@vger.kernel.org X-Gm-Message-State: AOJu0Yx7dgLhBW/MdbjY2vw+Wu1tFhHwJC35RIvLXIVG9j/BDIOZMfRI sVdZ2RoHmeQrZ5uT/bpAJy+uX1nDEMcN8EvEtWNQeSmTDL/az0s3WBQ19G1veVNaOjcNFX2+DuO aGNcjuexI3H37EAfHbKX6CKsx+XWNrBYQEBVeoZ/LX3m6BxQP9rKRlsft8bqK5nsmrw== X-Gm-Gg: AeBDiet+Td1d1Mph9hZD5rL84pWjCITbnIaukVxWnm5CZ2P2ZlEnr4vgUbSp6pMFCjh Zf8n3KWPkJrUITw7MlxA3DIfm4VaAABCYfymZwhQCYNDJnc9GbJy/FzzRrprbZghfRGVELJPlGQ j7WQIF9inm8k1OC++xk7NsYsDl8Opect5JKZUVRhdWNs+xSmAfqy1LYk8iIrXkN4RKx1K2vtwoY BNH4/Xype7nLVO5vNp5rge1XaUaQLHxh0pcKE3mdDHzml1yt2KsaVycDKihYjsEm56DbFSCy6xc buf3xeJgHnBkCm4IV+cWlf72TeLcmCzo2u+Vxejk3MJ1qBVyUziBkdJXYX5nqbhpasAcs6VaSqt I+PGQ8XLzlOBsQJ9lpgwMCH8m3PTAyowtEwt4UEpZGICPzPLLN5K58jh/zLGkZC4= X-Received: by 2002:a05:690c:6983:b0:7b4:31cc:376d with SMTP id 00721157ae682-7b431cc3be3mr122199927b3.39.1776289709933; Wed, 15 Apr 2026 14:48:29 -0700 (PDT) X-Received: by 2002:a05:690c:6983:b0:7b4:31cc:376d with SMTP id 00721157ae682-7b431cc3be3mr122199647b3.39.1776289709499; Wed, 15 Apr 2026 14:48:29 -0700 (PDT) Received: from li-4c4c4544-0032-4210-804c-c3c04f423534.ibm.com ([2600:1700:6476:1430::29]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7b768d3a990sm14025537b3.26.2026.04.15.14.48.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 14:48:29 -0700 (PDT) Message-ID: <1929bc40bee602937aac95a3d338614b5fe7e082.camel@redhat.com> Subject: Re: [PATCH v3] hfsplus: fix null-ptr-deref in hfsplus_cat_write_inode From: Viacheslav Dubeyko To: Deepanshu Kartikey , slava@dubeyko.com, glaubitz@physik.fu-berlin.de, frank.li@vivo.com Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+c0ba772a362e70937dfb@syzkaller.appspotmail.com Date: Wed, 15 Apr 2026 14:48:27 -0700 In-Reply-To: <20260415014345.77796-1-kartikey406@gmail.com> References: <20260415014345.77796-1-kartikey406@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43app2) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-04-15 at 07:13 +0530, Deepanshu Kartikey wrote: > When a corrupt HFS+ image is mounted where the hidden directory is > absent, hfsplus_fill_super() handles -ENOENT from > hfsplus_get_hidden_dir_entry() silently and continues with > sbi->hidden_dir left as NULL. >=20 > hfsplus_link() and hfsplus_unlink() call > hfsplus_cat_write_inode(sbi->hidden_dir) unconditionally without > checking whether hidden_dir is NULL, triggering a general protection > fault caught by KASAN as a null-ptr-deref at offset 0x28. >=20 > Other call sites in dir.c already guard against this by checking > hidden_dir for NULL before use. Apply the same guard to the two > unprotected call sites in hfsplus_link() and hfsplus_unlink(). >=20 > Changes in v3: > - Correct fix location: guard sbi->hidden_dir before calling > hfsplus_cat_write_inode() in hfsplus_link() and hfsplus_unlink() > in dir.c, as suggested by Vyacheslav Dubeyko. >=20 > Changes in v2: > - Fixed commit message: hfsplus_delete_cat() is called from > multiple callers, not just hfsplus_unlink() as incorrectly > stated in v1. >=20 > Reported-by: syzbot+c0ba772a362e70937dfb@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=3Dc0ba772a362e70937dfb > Tested-by: syzbot+c0ba772a362e70937dfb@syzkaller.appspotmail.com > Signed-off-by: Deepanshu Kartikey > --- > fs/hfsplus/dir.c | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) >=20 > diff --git a/fs/hfsplus/dir.c b/fs/hfsplus/dir.c > index d559bf8625f8..a7feef53d8cb 100644 > --- a/fs/hfsplus/dir.c > +++ b/fs/hfsplus/dir.c > @@ -362,9 +362,11 @@ static int hfsplus_link(struct dentry *src_dentry, s= truct inode *dst_dir, > if (res) > goto out; > =20 > - res =3D hfsplus_cat_write_inode(sbi->hidden_dir); > - if (res) > - goto out; > + if (sbi->hidden_dir) { > + res =3D hfsplus_cat_write_inode(sbi->hidden_dir); > + if (res) > + goto out; > + } > =20 > res =3D hfsplus_cat_write_inode(inode); > =20 > @@ -431,11 +433,10 @@ static int hfsplus_unlink(struct inode *dir, struct= dentry *dentry) > out: > if (!res) { > res =3D hfsplus_cat_write_inode(dir); > - if (!res) { > + if (!res && sbi->hidden_dir) > res =3D hfsplus_cat_write_inode(sbi->hidden_dir); > - if (!res) > - res =3D hfsplus_cat_write_inode(inode); > - } > + if (!res) > + res =3D hfsplus_cat_write_inode(inode); > } > =20 > mutex_unlock(&sbi->vh_mutex); As far as I can see, we have such logic in hfsplus_fill_super() [1]: if (!sb_rdonly(sb)) { if (!sbi->hidden_dir) {