CVE-2024-26972

kernel: ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path

Published May 1, 2024 CVSS 3.1 · 5.5 Medium EPSS n/a KEV · Not listed
Description
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Ubuntu USN Ubuntu USN USN-6816-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-6817-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-6817-2 Linux kernel (OEM) vulnerabilities
Ubuntu USN Ubuntu USN USN-6817-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-6878-1 Linux kernel (Oracle) vulnerabilities
History
Type Values Removed Values Added
Title ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path kernel: ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Type Values Removed Values Added
Weaknesses CWE-401

Subscriptions

No data.

Weaknesses

Sources

Status
REJECTED
Assigner
Linux
Published
Updated
Dec 19, 2024, 11:17 AM
Reserved
Feb 19, 2024, 2:20 PM
Status
Rejected
Published
May 1, 2024, 6:15 AM
Modified
Oct 16, 2026, 1:10 PM
Severity
Moderate
Public date
May 1, 2024, 12:00 AM