CVE WatchAug 4, 2026

CVE-2022-50335

In the Linux kernel, the following vulnerability has been resolved: 9p: set req refcount to zero to avoid uninitialized usage When a new r

CVSS

9.8

Critical

EPSS

0.4%

p31

KEV

—

Exploit Today

0-100

Published: Sep 15, 2025 · Last modified: Aug 4, 2026 · CWE-908

EPSS · 30d

0.4%EPSS · 30 days0.4%

2026-08-232026-09-20

Technical description

In the Linux kernel, the following vulnerability has been resolved: 9p: set req refcount to zero to avoid uninitialized usage When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110): p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client.c:1165 clone_fid fs/9p/fid.h:21 [inline] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [inline] v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 path_setxattr+0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [inline] __se_sys_setxattr fs/xattr.c:648 [inline] __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Below is a similar scenario, the scenario in the syzbot log looks more complicated than this one, but this patch can fix it. T21124 p9_read_work ======================== second trans ================================= p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == uninitialized */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* increments uninitalized refcount */ refcount_set(&req->refcount, 2); /* cb drops one ref */ p9_client_cb(req) /* reader thread drops its ref: request is incorrectly freed */ p9_req_put(req) /* use after free and ref underflow */ p9_req_put(req) To fix it, we can initialize the refcount to zero before add to idr.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-940567.5 HIG

16.1%

——5Exim before 4.100.1, when Proxy-Protocol is used with an attacker-controlled proxy, allows attackers to read certain uninitialized data from stack memory.1d CVE-2026-93018—

8.3%

——2Imager versions before 1.036 for Perl disclose uninitialised heap memory reading a paletted image with pixel indexes past its colour map in i_gpix_p and i_glin_p. The palette is allocated uninitialised, and only the entries a reader adds count as populated. The TGA reader stores pixel indexes without checking them against the colour map. i_gpix_p() rejects only an index greater than the count, so an index equal to it reads the first unpopulated entry, and getpixel() returns it. i_glin_p() skips any index at or beyond the count without writing that pixel to the caller's buffer. The palette-to-RGB conversion reads each row through an uninitialised buffer, so those pixels of the converted image hold prior heap contents. Reading an attacker-supplied image through Imager->read() and then fetching its pixels or converting it to RGB discloses process heap memory.2d CVE-2026-546347.3 HIG

16.8%

——5Hamlib is a ham radio control library for radios, rotators, and amplifiers. Prior to 4.7.2, the unauthenticated rigctld send_raw command on TCP port 4532 reaches rigctl_send_raw() in tests/rigctl_parse.c, which writes a NUL byte at buf[buf_len + 1] outside its 200-byte stack buffer, and rig_send_raw() in src/rig.c, which copies reply_len - 1 bytes instead of the actual nbytes received. A remote client can send the CR terminator with a short payload to trigger both flaws in one command under the default no-password configuration. The out-of-bounds write can crash the daemon or corrupt adjacent stack memory, while the oversized copy can return up to 198 bytes of uninitialized stack data to the client. This issue is fixed in version 4.7.2.3d CVE-2026-54604—

22.9%

——7OpenSlide is a C library for reading whole slide image files. Prior to 4.0.1, a behavior change in libtiff 4.7.1 causes the indirect TIFF tile path in src/openslide-decode-tiff.c and _openslide_tiff_read_tile() to request a full-height destination for a partial bottom tile row, allowing uninitialized heap memory to enter pixel data returned by openslide_read_region(). A crafted but valid slide can trigger the issue in TIFF-based formats other than Hamamatsu NDPI when a network service renders attacker-provided slides. Successful extraction depends on pixel transparency handling and recompression, OpenSlide with libtiff 4.7.0 or earlier is not affected, and official binary builds 4.0.0.10 and 4.0.0.11 are affected. This issue is fixed in OpenSlide 4.0.1 and official binary build 4.0.0.12.2d CVE-2026-917404.3 MED

16.4%

——5Uninitialized resource in Skia in Google Chrome prior to 153.0.8010.47 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High)4d CVE-2026-917204.7 MED

20.4%

——6Uninitialized resource in ANGLE in Google Chrome prior to 153.0.8010.47 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High)4d