From nobody Tue Dec 16 07:30:51 2025 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.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 47BD0357A36 for ; Fri, 5 Dec 2025 18:39:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764959966; cv=none; b=Hoc94PoHsYAIu54tCxcYqhqikgud6PG3BwCqnq+3da8fQW9q9IR/P6j3oiQ8FIX3prvI9PuKdIqKoUc5TM8l6bpBDCTXU8xJUeVTZekmaZqPHlKf9lw3M6/RzHg3OwnvfmrQGtr4HbqNv1lsoRt5FAex1hPeqWscQDHIi2s89Os= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764959966; c=relaxed/simple; bh=cjNKHrQrnXLTUtPo/NH2OLDEK0teLVgujXCxRj1xbCc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=GDyV6/0N7+s+OujGrWCfvThqoexnT1ocd/xq3R6I8zuxE0J2sbFLbWdiKFRqg4bMNMyPmf3UNbbICtgBrg0w79wRPo+tNu+HK/C99asHEcGLQawklJcfT6bl4lCNdrp52mUolGWPQRSvf3SU7NiqU6d5i6I5z22KKHuRxwEzsq8= 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=LCehPqhH; arc=none smtp.client-ip=209.85.215.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="LCehPqhH" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-bfb84c2fe5eso359376a12.1 for ; Fri, 05 Dec 2025 10:39:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764959962; x=1765564762; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=F3b2MXk7/01ozYqBLq6Lp8YCFWTmwEngfJtvZiESMsc=; b=LCehPqhHYlPhn091Z6OkrTl1AN1hYG4bEU13wH0hEI3YAxO7Q3K1AbXnphUdpwekNL ztXjpPsnuYjtMUxDVXPZmERNL37pQ0SafdgdPjJ5J/tcXD/amfqnBD/FO1mavAMXKroU XIudvjucBfXXpHew6B3nENEBJ67GT9ojSPM8F3pBpF9ZegNiWcm1kG3GTY0aua0Dzrt/ gWtFuIJfGzLROUzVCuKGo0wnwjZSsvNO9Dji1IGCLha9+i47H68IQUmx7Npn+R2A2dUN FqOTP0mvelyd+PS5iH80PoaiN6pJ0W9VAu2ZAmKnaHa2o2Al4qXOFjijuJVOTlWdKic/ kiEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764959962; x=1765564762; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=F3b2MXk7/01ozYqBLq6Lp8YCFWTmwEngfJtvZiESMsc=; b=Kw4ca1DMXrFUOyWuETdvfMgY0XiYMeZU6VPaAHjvz4PLWHC+JoCDHphxDlHv1FSmBT Cr8Wc9pdMXqxvorHpH4VxDun2I2j6OonF28SlwrQZKswGAfIw+ZE3T8TzkgsliZ9Qt1x GZgi+a9NgGc9eKsCGufn8OOlNPdTwvjdOIKkVt6FfCDZH1rAH7RkCquIy08KSdnIQIic F4xgKRl3Cp21xX0NiHHKsko0TOg7THVhJQBKE3ldZFi/h4A4gPaxmxkOjNczhJMoliv0 z3be8rCfG5P5BrgfW/1CfE3NPYrE86UsxrghqMEdFeEJpolWb1+f1T3KTg0lKkGKjbuB PdQQ== X-Forwarded-Encrypted: i=1; AJvYcCVVdAt7dQ+Cwb9jX77jYq04JaXp6nPXayDyB8F7knetH5QJEpjm5OK183TSB2pKnYQA14vH68YBBkiALnU=@vger.kernel.org X-Gm-Message-State: AOJu0YwxiiFjjwkexrRNR1GWJCtbVMPWpF3NlrXjlKTZg/gfN7oQWaQx kqBqlsp3v6jKq6KWpyuz+/3Q9uBZY/edakNKcyxqmJDAFJh4VIZMYE844QtYx2DkN0s= X-Gm-Gg: ASbGnctjFKoToE2Knxwu0/5Xcsdw1e9MjQ7iKcj3t/hIonAxM1STjF5jTS4GWzUcyD/ 0HPwWOM2EWVTFGTxhir+GglrExKn7hPDDLGoR0EF6W7vDUiLMgsyx2yecbbmA2iFuU0LRPo9O4O ycZk03YDLd1NiX+QnYm5fY76PNibi5l26R130efOj27d18A0+r5hRtnO/nEVRQUoqVfTManDSvP sZ86EPMERDNXCMpMs2QM1YxGjEFQ79W1YctzBBFTMIjGA393NfXanxjxWP45yh1oIzkp3abD8ko vx6XVPoZNPo2naTCkapSFmI1aWEtewxFA62m+U+bmdQ5rxIgmU6/V3KeNdJ2rtgQsb+6Qniiu/e YsxWPIex2Edno5RR7tOMwrpaxdq9sDdwzKioZohmcvSClK/AhfKsYomVvcfbqcBrb+uaksOiUFT AkNdSYZJyvEdeUghWXHI+K7mzSnW6Pig== X-Google-Smtp-Source: AGHT+IGp/pD+55VxfNaGNlZMHcVDyCZzwtjcXLNX3ZsgvJQlW5QwGHduUe4BhdJ+a4kKFe7mkksxqg== X-Received: by 2002:a17:90b:2e8c:b0:343:3898:e7c7 with SMTP id 98e67ed59e1d1-349a1c84d90mr160863a91.12.1764959961918; Fri, 05 Dec 2025 10:39:21 -0800 (PST) Received: from LilGuy ([2409:40c2:102b:bda0:cf8c:6055:172b:8eed]) by smtp.googlemail.com with ESMTPSA id 98e67ed59e1d1-3494ea899desm5326165a91.17.2025.12.05.10.39.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Dec 2025 10:39:21 -0800 (PST) From: Swaraj Gaikwad To: syzbot+99f6ed51479b86ac4c41@syzkaller.appspotmail.com Cc: frank.li@vivo.com, glaubitz@physik.fu-berlin.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, slava@dubeyko.com, skhan@linuxfoundation.org, david.hunter.linux@gmail.com, syzkaller-bugs@googlegroups.com, Swaraj Gaikwad Subject: [PATCH v1] hfsplus: fix memory leak on mount failure Date: Sat, 6 Dec 2025 00:09:02 +0000 Message-ID: <20251206000902.71178-1-swarajgaikwad1925@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <69326fcf.a70a0220.d98e3.01e5.GAE@google.com> References: <69326fcf.a70a0220.d98e3.01e5.GAE@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable syzbot reported a memory leak in the hfsplus mount path when the mount fails, which occurs because the fs_context API moves ownership of fc->s_fs_info to sb->s_fs_info early in sget_fc(). When filesystems are mounted using the new API, the VFS (specifically sget_fc) transfers the ownership of the context's s_fs_info (the 'sbi' struct) to the superblock (sb->s_fs_info) and clears the context pointer. If the mount fails after this transfer the VFS calls deactivate_locked_super, which invokes the filesystem's kill_sb callback. Previously, hfsplus used the generic kill_block_super, which does not free sb->s_fs_info, resulting in the 'sbi' structure and its loaded NLS tables being leaked. Fix this by implementing a filesystem-specific ->kill_sb() that frees sb->s_fs_info and its NLS resources before calling kill_block_super(). Also remove the early kfree(sbi) from hfsplus_fill_super()=E2=80=99s error = path, because the superblock unconditionally owns s_fs_info when using the fs_context API. Testing: This fix was verified by building the kernel with the .config provided by the syzkaller reporter and running the reproducer. The reproducer now runs successfully without triggering any memory leaks or kernel errors. #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= e69c7c175115 Reported-by: syzbot+99f6ed51479b86ac4c41@syzkaller.appspotmail.com Signed-off-by: Swaraj Gaikwad --- fs/hfsplus/super.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index 16bc4abc67e0..fa7420d08da1 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -629,7 +629,6 @@ static int hfsplus_fill_super(struct super_block *sb, s= truct fs_context *fc) out_unload_nls: unload_nls(sbi->nls); unload_nls(nls); - kfree(sbi); return err; } @@ -688,10 +687,23 @@ static int hfsplus_init_fs_context(struct fs_context = *fc) return 0; } +static void hfsplus_kill_sb(struct super_block *sb) +{ + struct hfsplus_sb_info *sbi =3D HFSPLUS_SB(sb); + + if (sbi) { + unload_nls(sbi->nls); + kfree(sbi); + sb->s_fs_info =3D NULL; + } + + kill_block_super(sb); +} + static struct file_system_type hfsplus_fs_type =3D { .owner =3D THIS_MODULE, .name =3D "hfsplus", - .kill_sb =3D kill_block_super, + .kill_sb =3D hfsplus_kill_sb, .fs_flags =3D FS_REQUIRES_DEV, .init_fs_context =3D hfsplus_init_fs_context, }; base-commit: 6bda50f4333fa61c07f04f790fdd4e2c9f4ca610 -- 2.52.0