AI Trajectory

null

{
  "EnableConfigs": [
    "HFS_FS"
  ],
  "FocusSymbols": [
    "hfs_cat_find_brec",
    "hfs_read_inode",
    "hfs_file_lookup",
    "hfs_fill_super"
  ],
  "Reasoning": "The patch adds validation for Catalog Node IDs (CNID) and checks for bad inodes in the HFS filesystem driver. This is a functional change that affects how HFS parses on-disk structures and handles corrupted images, which is reachable by mounting an HFS image.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 5545ed760094cc8d832dee40b56a958c1f0fe0a4\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Thu Jul 9 15:47:47 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/fs/hfs/catalog.c b/fs/hfs/catalog.c\nindex 1bfa36d71e247a..490c5e130da3b6 100644\n--- a/fs/hfs/catalog.c\n+++ b/fs/hfs/catalog.c\n@@ -182,6 +182,40 @@ int hfs_cat_keycmp(const btree_key *key1, const btree_key *key2)\n \t\t\t  key2-\u003ecat.CName.name, key2-\u003ecat.CName.len);\n }\n \n+static int hfs_cat_validate_found_cnid(struct hfs_find_data *fd, u32 cnid)\n+{\n+\thfs_cat_rec rec;\n+\tu32 found_cnid;\n+\tint rec_len;\n+\n+\trec_len = fd-\u003eentrylength;\n+\tif (rec_len \u003c= 0 || (size_t)rec_len \u003e sizeof(rec))\n+\t\treturn -EIO;\n+\n+\tmemset(\u0026rec, 0, sizeof(rec));\n+\thfs_bnode_read(fd-\u003ebnode, \u0026rec, fd-\u003eentryoffset, rec_len);\n+\n+\tswitch (rec.type) {\n+\tcase HFS_CDR_FIL:\n+\t\tif ((size_t)rec_len != sizeof(struct hfs_cat_file))\n+\t\t\treturn -EIO;\n+\t\tfound_cnid = be32_to_cpu(rec.file.FlNum);\n+\t\tbreak;\n+\tcase HFS_CDR_DIR:\n+\t\tif ((size_t)rec_len != sizeof(struct hfs_cat_dir))\n+\t\t\treturn -EIO;\n+\t\tfound_cnid = be32_to_cpu(rec.dir.DirID);\n+\t\tbreak;\n+\tdefault:\n+\t\treturn -EIO;\n+\t}\n+\n+\tif (found_cnid != cnid)\n+\t\treturn -EIO;\n+\n+\treturn 0;\n+}\n+\n /* Try to get a catalog entry for given catalog id */\n // move to read_super???\n int hfs_cat_find_brec(struct super_block *sb, u32 cnid,\n@@ -208,7 +242,12 @@ int hfs_cat_find_brec(struct super_block *sb, u32 cnid,\n \t\treturn -EIO;\n \t}\n \tmemcpy(fd-\u003esearch_key-\u003ecat.CName.name, rec.thread.CName.name, len);\n-\treturn hfs_brec_find(fd);\n+\n+\tres = hfs_brec_find(fd);\n+\tif (res)\n+\t\treturn res;\n+\n+\treturn hfs_cat_validate_found_cnid(fd, cnid);\n }\n \n static inline\ndiff --git a/fs/hfs/hfs_fs.h b/fs/hfs/hfs_fs.h\nindex f3624514fcb030..670638f17438ce 100644\n--- a/fs/hfs/hfs_fs.h\n+++ b/fs/hfs/hfs_fs.h\n@@ -155,6 +155,25 @@ extern int hfs_cat_move(u32 cnid, struct inode *src_dir,\n extern void hfs_cat_build_key(struct super_block *sb, btree_key *key,\n \t\t\t      u32 parent, const struct qstr *name);\n \n+/*\n+ * Validate the CNID of a catalog record.\n+ */\n+static inline bool hfs_is_valid_cnid(u32 cnid, u8 type)\n+{\n+\tif (likely(cnid \u003e= HFS_FIRSTUSER_CNID))\n+\t\treturn true;\n+\n+\tswitch (cnid) {\n+\tcase HFS_ROOT_CNID:\n+\t\treturn type == HFS_CDR_DIR;\n+\tcase HFS_EXT_CNID:\n+\tcase HFS_CAT_CNID:\n+\t\treturn type == HFS_CDR_FIL;\n+\tdefault:\n+\t\treturn false;\n+\t}\n+}\n+\n /* dir.c */\n extern const struct file_operations hfs_dir_operations;\n extern const struct inode_operations hfs_dir_inode_operations;\ndiff --git a/fs/hfs/inode.c b/fs/hfs/inode.c\nindex ac4a9055c5c0ea..c9e75c2e576a3f 100644\n--- a/fs/hfs/inode.c\n+++ b/fs/hfs/inode.c\n@@ -367,6 +367,9 @@ static int hfs_read_inode(struct inode *inode, void *data)\n \trec = idata-\u003erec;\n \tswitch (rec-\u003etype) {\n \tcase HFS_CDR_FIL:\n+\t\tif (!hfs_is_valid_cnid(be32_to_cpu(rec-\u003efile.FlNum), rec-\u003etype))\n+\t\t\treturn -EIO;\n+\n \t\tif (!HFS_IS_RSRC(inode)) {\n \t\t\thfs_inode_read_fork(inode, rec-\u003efile.ExtRec, rec-\u003efile.LgLen,\n \t\t\t\t\t    rec-\u003efile.PyLen, be16_to_cpu(rec-\u003efile.ClpSize));\n@@ -390,6 +393,9 @@ static int hfs_read_inode(struct inode *inode, void *data)\n \t\tinode-\u003ei_mapping-\u003ea_ops = \u0026hfs_aops;\n \t\tbreak;\n \tcase HFS_CDR_DIR:\n+\t\tif (!hfs_is_valid_cnid(be32_to_cpu(rec-\u003edir.DirID), rec-\u003etype))\n+\t\t\treturn -EIO;\n+\n \t\tinode-\u003ei_ino = be32_to_cpu(rec-\u003edir.DirID);\n \t\tinode-\u003ei_size = be16_to_cpu(rec-\u003edir.Val) + 2;\n \t\tHFS_I(inode)-\u003efs_blocks = 0;\n@@ -571,13 +577,18 @@ static struct dentry *hfs_file_lookup(struct inode *dir, struct dentry *dentry,\n \tres = hfs_brec_read(\u0026fd, \u0026rec, sizeof(rec));\n \tif (!res) {\n \t\tstruct hfs_iget_data idata = { NULL, \u0026rec };\n-\t\thfs_read_inode(inode, \u0026idata);\n+\t\tres = hfs_read_inode(inode, \u0026idata);\n \t}\n \thfs_find_exit(\u0026fd);\n \tif (res) {\n \t\tiput(inode);\n \t\treturn ERR_PTR(res);\n \t}\n+\n+\tif (is_bad_inode(inode)) {\n+\t\tiput(inode);\n+\t\treturn ERR_PTR(-EIO);\n+\t}\n \tHFS_I(inode)-\u003ersrc_inode = dir;\n \tHFS_I(dir)-\u003ersrc_inode = inode;\n \tigrab(dir);\ndiff --git a/fs/hfs/super.c b/fs/hfs/super.c\nindex a466c401f6bb26..98b80795bcde9a 100644\n--- a/fs/hfs/super.c\n+++ b/fs/hfs/super.c\n@@ -372,6 +372,11 @@ static int hfs_fill_super(struct super_block *sb, struct fs_context *fc)\n \tif (!root_inode)\n \t\tgoto bail_no_root;\n \n+\tif (is_bad_inode(root_inode)) {\n+\t\tiput(root_inode);\n+\t\tgoto bail_no_root;\n+\t}\n+\n \tset_default_d_op(sb, \u0026hfs_dentry_operations);\n \tres = -ENOMEM;\n \tsb-\u003es_root = d_make_root(root_inode);\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "HFS_FS"
  ],
  "FocusSymbols": [
    "hfs_cat_find_brec",
    "hfs_read_inode",
    "hfs_file_lookup",
    "hfs_fill_super"
  ],
  "Reasoning": "The patch adds validation for Catalog Node IDs (CNID) and checks for bad inodes in the HFS filesystem driver. This is a functional change that affects how HFS parses on-disk structures and handles corrupted images, which is reachable by mounting an HFS image.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 5545ed760094cc8d832dee40b56a958c1f0fe0a4
Author: syz-cluster <triage@syzkaller.com>
Date:   Thu Jul 9 15:47:47 2026 +0000

    syz-cluster: applied patch under review

diff --git a/fs/hfs/catalog.c b/fs/hfs/catalog.c
index 1bfa36d71e247a..490c5e130da3b6 100644
--- a/fs/hfs/catalog.c
+++ b/fs/hfs/catalog.c
@@ -182,6 +182,40 @@ int hfs_cat_keycmp(const btree_key *key1, const btree_key *key2)
 			  key2->cat.CName.name, key2->cat.CName.len);
 }
 
+static int hfs_cat_validate_found_cnid(struct hfs_find_data *fd, u32 cnid)
+{
+	hfs_cat_rec rec;
+	u32 found_cnid;
+	int rec_len;
+
+	rec_len = fd->entrylength;
+	if (rec_len <= 0 || (size_t)rec_len > sizeof(rec))
+		return -EIO;
+
+	memset(&rec, 0, sizeof(rec));
+	hfs_bnode_read(fd->bnode, &rec, fd->entryoffset, rec_len);
+
+	switch (rec.type) {
+	case HFS_CDR_FIL:
+		if ((size_t)rec_len != sizeof(struct hfs_cat_file))
+			return -EIO;
+		found_cnid = be32_to_cpu(rec.file.FlNum);
+		break;
+	case HFS_CDR_DIR:
+		if ((size_t)rec_len != sizeof(struct hfs_cat_dir))
+			return -EIO;
+		found_cnid = be32_to_cpu(rec.dir.DirID);
+		break;
+	default:
+		return -EIO;
+	}
+
+	if (found_cnid != cnid)
+		return -EIO;
+
+	return 0;
+}
+
 /* Try to get a catalog entry for given catalog id */
 // move to read_super???
 int hfs_cat_find_brec(struct super_block *sb, u32 cnid,
@@ -208,7 +242,12 @@ int hfs_cat_find_brec(struct super_block *sb, u32 cnid,
 		return -EIO;
 	}
 	memcpy(fd->search_key->cat.CName.name, rec.thread.CName.name, len);
-	return hfs_brec_find(fd);
+
+	res = hfs_brec_find(fd);
+	if (res)
+		return res;
+
+	return hfs_cat_validate_found_cnid(fd, cnid);
 }
 
 static inline
diff --git a/fs/hfs/hfs_fs.h b/fs/hfs/hfs_fs.h
index f3624514fcb030..670638f17438ce 100644
--- a/fs/hfs/hfs_fs.h
+++ b/fs/hfs/hfs_fs.h
@@ -155,6 +155,25 @@ extern int hfs_cat_move(u32 cnid, struct inode *src_dir,
 extern void hfs_cat_build_key(struct super_block *sb, btree_key *key,
 			      u32 parent, const struct qstr *name);
 
+/*
+ * Validate the CNID of a catalog record.
+ */
+static inline bool hfs_is_valid_cnid(u32 cnid, u8 type)
+{
+	if (likely(cnid >= HFS_FIRSTUSER_CNID))
+		return true;
+
+	switch (cnid) {
+	case HFS_ROOT_CNID:
+		return type == HFS_CDR_DIR;
+	case HFS_EXT_CNID:
+	case HFS_CAT_CNID:
+		return type == HFS_CDR_FIL;
+	default:
+		return false;
+	}
+}
+
 /* dir.c */
 extern const struct file_operations hfs_dir_operations;
 extern const struct inode_operations hfs_dir_inode_operations;
diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
index ac4a9055c5c0ea..c9e75c2e576a3f 100644
--- a/fs/hfs/inode.c
+++ b/fs/hfs/inode.c
@@ -367,6 +367,9 @@ static int hfs_read_inode(struct inode *inode, void *data)
 	rec = idata->rec;
 	switch (rec->type) {
 	case HFS_CDR_FIL:
+		if (!hfs_is_valid_cnid(be32_to_cpu(rec->file.FlNum), rec->type))
+			return -EIO;
+
 		if (!HFS_IS_RSRC(inode)) {
 			hfs_inode_read_fork(inode, rec->file.ExtRec, rec->file.LgLen,
 					    rec->file.PyLen, be16_to_cpu(rec->file.ClpSize));
@@ -390,6 +393,9 @@ static int hfs_read_inode(struct inode *inode, void *data)
 		inode->i_mapping->a_ops = &hfs_aops;
 		break;
 	case HFS_CDR_DIR:
+		if (!hfs_is_valid_cnid(be32_to_cpu(rec->dir.DirID), rec->type))
+			return -EIO;
+
 		inode->i_ino = be32_to_cpu(rec->dir.DirID);
 		inode->i_size = be16_to_cpu(rec->dir.Val) + 2;
 		HFS_I(inode)->fs_blocks = 0;
@@ -571,13 +577,18 @@ static struct dentry *hfs_file_lookup(struct inode *dir, struct dentry *dentry,
 	res = hfs_brec_read(&fd, &rec, sizeof(rec));
 	if (!res) {
 		struct hfs_iget_data idata = { NULL, &rec };
-		hfs_read_inode(inode, &idata);
+		res = hfs_read_inode(inode, &idata);
 	}
 	hfs_find_exit(&fd);
 	if (res) {
 		iput(inode);
 		return ERR_PTR(res);
 	}
+
+	if (is_bad_inode(inode)) {
+		iput(inode);
+		return ERR_PTR(-EIO);
+	}
 	HFS_I(inode)->rsrc_inode = dir;
 	HFS_I(dir)->rsrc_inode = inode;
 	igrab(dir);
diff --git a/fs/hfs/super.c b/fs/hfs/super.c
index a466c401f6bb26..98b80795bcde9a 100644
--- a/fs/hfs/super.c
+++ b/fs/hfs/super.c
@@ -372,6 +372,11 @@ static int hfs_fill_super(struct super_block *sb, struct fs_context *fc)
 	if (!root_inode)
 		goto bail_no_root;
 
+	if (is_bad_inode(root_inode)) {
+		iput(root_inode);
+		goto bail_no_root;
+	}
+
 	set_default_d_op(sb, &hfs_dentry_operations);
 	res = -ENOMEM;
 	sb->s_root = d_make_root(root_inode);

gemini-3.1-pro-preview

null

null

							input: 3645
							output: 31
							thoughts: 160
						

**My Assessment of the HFS Filesystem Patch**

Okay, so I've got this patch here that's poking around in the HFS filesystem driver, specifically `fs/hfs/`. It seems the focus is on tightening up CNID validation – that's good, especially with `hfs_cat_validate_found_cnid` and `hfs_is_valid_cnid` getting some attention. It's also adding checks for `is_bad_inode` in the lookup function (`hfs_file_lookup`) and during superblock initialization (`hfs_fill_super`). 

This is a functional change, a pretty clear indication that it's altering the behavior of the HFS filesystem. Since HFS is reachable, meaning we can mount an HFS image and trigger these changes, fuzzing is definitely warranted. It looks like it's touching all the right places for potential vulnerabilities.

Now, let's figure out the right configuration options. I'll fire up `grepper` and search the Kconfig files for `fs/hfs/`, or maybe just a direct `CONFIG_HFS_FS` will do the trick. Knowing the configuration is key for testing this properly.

{
  "Expression": "HFS_FS",
  "PathPrefix": "fs/hfs/Kconfig"
}

{
  "Output": "fs/hfs/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\nfs/hfs/Kconfig:2:config HFS_FS\nfs/hfs/Kconfig-3-\ttristate \"Apple Macintosh file system support\"\n--\nfs/hfs/Kconfig=17=config HFS_KUNIT_TEST\nfs/hfs/Kconfig-18-\ttristate \"KUnit tests for HFS filesystem\" if !KUNIT_ALL_TESTS\nfs/hfs/Kconfig:19:\tdepends on HFS_FS \u0026\u0026 KUNIT\nfs/hfs/Kconfig-20-\tdefault KUNIT_ALL_TESTS\n"
}

gemini-3.1-pro-preview

null

null

							input: 4267
							output: 34
							thoughts: 290
						

**Analyzing the HFS Filesystem Configuration**

Okay, so the configuration I'm working with is `HFS_FS`. Right, let's get down to identifying the key symbols we need to focus on. Based on the diffs, here are the functions that have been touched: `hfs_cat_validate_found_cnid`, `hfs_cat_find_brec`, `hfs_is_valid_cnid`, `hfs_read_inode`, `hfs_file_lookup`, and `hfs_fill_super`.

Now, let's strategically think about these. I'll need to dig into `hfs_cat_find_brec`, `hfs_read_inode`, `hfs_file_lookup`, and `hfs_fill_super`. While `hfs_cat_validate_found_cnid` is listed, it's marked as static, meaning it could be inlined. I'll include it in the list for now, just to be thorough. I need to keep in mind, however, that syzkaller might not directly discover inlined static functions, even if they are listed as part of the modifications. But, its caller `hfs_cat_find_brec` will still be relevant. Looks like `hfs_read_inode`, `hfs_file_lookup`, and `hfs_fill_super` are also static.

To start, I'll examine `fs/hfs/catalog.c` to understand the workings of `hfs_cat_find_brec`.

{
  "Expression": "hfs_cat_find_brec",
  "PathPrefix": "fs/hfs/"
}

{
  "Output": "fs/hfs/catalog.c=185=static int hfs_cat_validate_found_cnid(struct hfs_find_data *fd, u32 cnid)\n--\nfs/hfs/catalog.c-220-// move to read_super???\nfs/hfs/catalog.c:221:int hfs_cat_find_brec(struct super_block *sb, u32 cnid,\nfs/hfs/catalog.c-222-\t\t      struct hfs_find_data *fd)\n--\nfs/hfs/hfs_fs.h=145=struct hfs_find_data;\nfs/hfs/hfs_fs.h:146:extern int hfs_cat_find_brec(struct super_block *sb, u32 cnid,\nfs/hfs/hfs_fs.h-147-\t\t\t     struct hfs_find_data *fd);\n--\nfs/hfs/super.c=316=static int hfs_fill_super(struct super_block *sb, struct fs_context *fc)\n--\nfs/hfs/super.c-356-\t\tgoto bail_no_root;\nfs/hfs/super.c:357:\tres = hfs_cat_find_brec(sb, HFS_ROOT_CNID, \u0026fd);\nfs/hfs/super.c-358-\tif (!res) {\n"
}

gemini-3.1-pro-preview

null

null

							input: 5294
							output: 34
							thoughts: 187
						

**Analyzing HFS Filesystem Functions**

Okay, so I'm looking at these HFS filesystem functions. It seems `hfs_cat_find_brec` is exported, meaning it's visible outside its original source, and it's being called from within `hfs_fill_super`. Interesting.

Then there's `hfs_read_inode`. I see it's marked as `static` in `fs/hfs/inode.c`, along with `hfs_file_lookup`. And `hfs_fill_super` is also `static`, but that's in `fs/hfs/super.c`.

To make sure I'm following this correctly, let's list them to be absolutely clear:

*   `hfs_cat_find_brec`
*   `hfs_read_inode`
*   `hfs_file_lookup`
*   `hfs_fill_super`

Wait a minute, `hfs_read_inode` being static is unusual, but it might still be a useful point of examination, it depends on how it is being used. I need to dig into `hfs_read_inode` further and find out if it's acting as a callback or is being directly invoked. That will inform my next steps.

{
  "Expression": "hfs_read_inode",
  "PathPrefix": "fs/hfs/inode.c"
}

{
  "Output": "fs/hfs/inode.c=325=static int hfs_test_inode(struct inode *inode, void *data)\n--\nfs/hfs/inode.c-342-/*\nfs/hfs/inode.c:343: * hfs_read_inode\nfs/hfs/inode.c-344- */\nfs/hfs/inode.c:345:static int hfs_read_inode(struct inode *inode, void *data)\nfs/hfs/inode.c-346-{\n--\nfs/hfs/inode.c=425=struct inode *hfs_iget(struct super_block *sb, struct hfs_cat_key *key, hfs_cat_rec *rec)\n--\nfs/hfs/inode.c-440-\t}\nfs/hfs/inode.c:441:\tinode = iget5_locked(sb, cnid, hfs_test_inode, hfs_read_inode, \u0026data);\nfs/hfs/inode.c-442-\tif (inode \u0026\u0026 (inode_state_read_once(inode) \u0026 I_NEW))\n--\nfs/hfs/inode.c=552=static struct dentry *hfs_file_lookup(struct inode *dir, struct dentry *dentry,\n--\nfs/hfs/inode.c-579-\t\tstruct hfs_iget_data idata = { NULL, \u0026rec };\nfs/hfs/inode.c:580:\t\tres = hfs_read_inode(inode, \u0026idata);\nfs/hfs/inode.c-581-\t}\n"
}

gemini-3.1-pro-preview

null

null

							input: 6209
							output: 129
							thoughts: 206
						

**Analyzing the HFS Filesystem Driver Patch**

Okay, so I'm looking at this patch and my initial thought is, "Right, `hfs_read_inode` is definitely a key player here." I remember seeing it called as a callback within `iget5_locked` – that's a classic – and also directly in `hfs_file_lookup`. Good to confirm that.

Let's break this down further and list the relevant symbols. I'm seeing:

*   `hfs_cat_find_brec`
*   `hfs_read_inode`
*   `hfs_file_lookup`
*   `hfs_fill_super`

Now, the gist of this patch seems to be about validating Catalog Node IDs (CNIDs) and doing more robust checking for potentially corrupt inodes within the HFS filesystem driver. This is a *functional* change – it's directly impacting how the driver interprets on-disk data structures and, importantly, how it handles potential corruption. Clearly, this is something triggered by mounting an HFS image.

Before going any further, let me just double-check the configuration symbol. Yes, `HFS_FS` is the correct one. That's good to know.

Okay, let's keep these four symbols - `hfs_cat_find_brec`, `hfs_read_inode`, `hfs_file_lookup`, and `hfs_fill_super` - front of mind as I dig deeper. They’re the key entry points for understanding the patch's impact.

{
  "EnableConfigs": [
    "HFS_FS"
  ],
  "FocusSymbols": [
    "hfs_cat_find_brec",
    "hfs_read_inode",
    "hfs_file_lookup",
    "hfs_fill_super"
  ],
  "Reasoning": "The patch adds validation for Catalog Node IDs (CNID) and checks for bad inodes in the HFS filesystem driver. This is a functional change that affects how HFS parses on-disk structures and handles corrupted images, which is reachable by mounting an HFS image.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "HFS_FS"
  ],
  "FocusSymbols": [
    "hfs_cat_find_brec",
    "hfs_read_inode",
    "hfs_file_lookup",
    "hfs_fill_super"
  ],
  "Reasoning": "The patch adds validation for Catalog Node IDs (CNID) and checks for bad inodes in the HFS filesystem driver. This is a functional change that affects how HFS parses on-disk structures and handles corrupted images, which is reachable by mounting an HFS image.",
  "WorthFuzzing": true
}