{"id":"CVE-2022-49810","title":"netfs: Fix missing xas_retry() calls in xarray iteration","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix missing xas_retry() calls in xarray iteration\n\nnetfslib has a number of places in which it performs iteration of an xarray\nwhilst being under the RCU read lo…","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= 3d3c95046742e4eebaa4b891b0b01cbbed94ebbd < b2cc07a76f1eb12de3b22caf5fdbf856a7bef16d","Linux >= 3d3c95046742e4eebaa4b891b0b01cbbed94ebbd < 7e043a80b5dae5c2d2cf84031501de7827fd6c00","Linux 5.13"],"ssvc":{"exploitation":"none","automatable":"no","technicalImpact":"partial","timestamp":"2026-11-05T19:49:08.202965Z"},"published":"2025-05-01","updated":"2026-11-05","sourceUpdated":"2026-11-05T19:49:50.528Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2022-49810","references":[{"url":"https://git.kernel.org/stable/c/b2cc07a76f1eb12de3b22caf5fdbf856a7bef16d"},{"url":"https://git.kernel.org/stable/c/7e043a80b5dae5c2d2cf84031501de7827fd6c00"}],"tags":["cve.org"],"epss":0.0017,"epssPercentile":0.06464,"ingestedAt":"2026-11-05T22:38:31.602Z","slug":"CVE-2022-49810","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix missing xas_retry() calls in xarray iteration\n\nnetfslib has a number of places in which it performs iteration of an xarray\nwhilst being under the RCU read lock.  It *should* call xas_retry() as the\nfirst thing inside of the loop and do \"continue\" if it returns true in case\nthe xarray walker passed out a special value indicating that the walk needs\nto be redone from the root[*].\n\nFix this by adding the missing retry checks.\n\n[*] I wonder if this should be done inside xas_find(), xas_next_node() and\n    suchlike, but I'm told that's not an simple change to effect.\n\nThis can cause an oops like that below.  Note the faulting address - this\nis an internal value (|0x2) returned from xarray.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000402\n...\nRIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs]\n...\nCall Trace:\n netfs_rreq_assess+0xa6/0x240 [netfs]\n netfs_readpage+0x173/0x3b0 [netfs]\n ? init_wait_var_entry+0x50/0x50\n filemap_read_page+0x33/0xf0\n filemap_get_pages+0x2f2/0x3f0\n filemap_read+0xaa/0x320\n ? do_filp_open+0xb2/0x150\n ? rmqueue+0x3be/0xe10\n ceph_read_iter+0x1fe/0x680 [ceph]\n ? new_sync_read+0x115/0x1a0\n new_sync_read+0x115/0x1a0\n vfs_read+0xf3/0x180\n ksys_read+0x5f/0xe0\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nChanges:\n========\nver #2)\n - Changed an unsigned int to a size_t to reduce the likelihood of an\n   overflow as per Willy's suggestion.\n - Added an additional patch to fix the maths.\n\n## Affected\n\n- `Linux >= 3d3c95046742e4eebaa4b891b0b01cbbed94ebbd < b2cc07a76f1eb12de3b22caf5fdbf856a7bef16d`\n- `Linux >= 3d3c95046742e4eebaa4b891b0b01cbbed94ebbd < 7e043a80b5dae5c2d2cf84031501de7827fd6c00`\n- `Linux 5.13`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}