From: Arnaud Lecomte contact@arnaud-lcm.com
[ Upstream commit c214006856ff52a8ff17ed8da52d50601d54f9ce ]
When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.
Reported-by: syzbot+cffd18309153948f3c3e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cffd18309153948f3c3e Tested-by: syzbot+cffd18309153948f3c3e@syzkaller.appspotmail.com Signed-off-by: Arnaud Lecomte contact@arnaud-lcm.com Signed-off-by: Dave Kleikamp dave.kleikamp@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Security Impact Analysis
This commit fixes a **critical out-of-bounds array access vulnerability** in the JFS filesystem that can be triggered by corrupted filesystem metadata. The vulnerability allows reading/writing beyond the bounds of the `dcp->stree[]` array.
## Specific Code Analysis
1. **The Vulnerability**: In `dbAllocAG()`, the code calculates a tree index `ti` at line 1390: ```c ti = bmp->db_agstart + bmp->db_agwidth * (agno & (agperlev - 1)); ``` This calculated value is then used directly to access the `stree` array at line 1407: ```c if (l2nb > dcp->stree[ti]) ```
2. **Missing Bounds Check**: Before this patch, there was **no validation** that `ti` falls within the valid range of the `stree` array. The `stree` array has a fixed size of `CTLTREESIZE` (1365 elements), and `nleafs` field indicates the actual number of valid leaves.
3. **The Fix**: The patch adds a critical bounds check (lines 1392-1396): ```c if (ti < 0 || ti >= le32_to_cpu(dcp->nleafs)) { jfs_error(bmp->db_ipbmap->i_sb, "Corrupt dmapctl page\n"); release_metapage(mp); return -EIO; } ```
## Why This Qualifies for Stable Backport
1. **Security Vulnerability**: This fixes a real security issue reported by syzbot that can be triggered by corrupted filesystem metadata, potentially leading to: - Kernel memory corruption - Information disclosure - System crashes - Potential privilege escalation
2. **Small, Contained Fix**: The patch is minimal (6 lines of code) and adds only a defensive bounds check without changing any logic or architecture.
3. **Clear Bug Fix**: This is purely a bug fix, not a feature addition or architectural change.
4. **No Side Effects**: The fix only adds validation that prevents invalid memory access. It doesn't change normal operation paths.
5. **Tested**: The commit indicates it was tested by syzbot, providing confidence in the fix.
6. **Follows Stable Rules**: - Fixes a real bug that users can hit - Minimal change (< 100 lines) - Obviously correct - Already tested - Fixes a security issue
7. **Critical Subsystem**: While JFS is not the most commonly used filesystem, it's still in active use, and filesystem corruption vulnerabilities are serious security issues that should be fixed in all supported kernels.
The vulnerability could be exploited by: - Mounting a specially crafted JFS filesystem image - Corrupting JFS metadata through other means - Potentially through unprivileged mount operations in containers
This is exactly the type of security fix that stable kernels exist to provide - protecting users from known vulnerabilities without requiring them to upgrade to newer kernel versions.
fs/jfs/jfs_dmap.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c index 35e063c9f3a4..5080d59089bd 100644 --- a/fs/jfs/jfs_dmap.c +++ b/fs/jfs/jfs_dmap.c @@ -1389,6 +1389,12 @@ dbAllocAG(struct bmap * bmp, int agno, s64 nblocks, int l2nb, s64 * results) (1 << (L2LPERCTL - (bmp->db_agheight << 1))) / bmp->db_agwidth; ti = bmp->db_agstart + bmp->db_agwidth * (agno & (agperlev - 1));
+ if (ti < 0 || ti >= le32_to_cpu(dcp->nleafs)) { + jfs_error(bmp->db_ipbmap->i_sb, "Corrupt dmapctl page\n"); + release_metapage(mp); + return -EIO; + } + /* dmap control page trees fan-out by 4 and a single allocation * group may be described by 1 or 2 subtrees within the ag level * dmap control page, depending upon the ag size. examine the ag's