CVE-2022-49810
published 2025-05-01CVE-2022-49810: In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing xas_retry() calls in xarray iteration netfslib has a number of places in…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.16%
5.6th percentile
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing xas_retry() calls in xarray iteration
netfslib has a number of places in which it performs iteration of an xarray
whilst being under the RCU read lock. It *should* call xas_retry() as the
first thing inside of the loop and do "continue" if it returns true in case
the xarray walker passed out a special value indicating that the walk needs
to be redone from the root[*].
Fix this by adding the missing retry checks.
[*] I wonder if this should be done inside xas_find(), xas_next_node() and
suchlike, but I'm told that's not an simple change to effect.
This can cause an oops like that below. Note the faulting address - this
is an internal value (|0x2) returned from xarray.
BUG: kernel NULL pointer dereference, address: 0000000000000402
...
RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs]
...
Call Trace:
netfs_rreq_assess+0xa6/0x240 [netfs]
netfs_readpage+0x173/0x3b0 [netfs]
? init_wait_var_entry+0x50/0x50
filemap_read_page+0x33/0xf0
filemap_get_pages+0x2f2/0x3f0
filemap_read+0xaa/0x320
? do_filp_open+0xb2/0x150
? rmqueue+0x3be/0xe10
ceph_read_iter+0x1fe/0x680 [ceph]
? new_sync_read+0x115/0x1a0
new_sync_read+0x115/0x1a0
vfs_read+0xf3/0x180
ksys_read+0x5f/0xe0
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
Changes:
ver #2)
- Changed an unsigned int to a size_t to reduce the likelihood of an
overflow as per Willy's suggestion.
- Added an additional patch to fix the maths.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.10-1 (bookworm) | linux 6.0.10-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 3d3c95046742e4eebaa4b891b0b01cbbed94ebbd < b2cc07a76f1eb12de3b22caf5fdbf856a7bef16d | b2cc07a76f1eb12de3b22caf5fdbf856a7bef16d |
| linux | linux | >= 3d3c95046742e4eebaa4b891b0b01cbbed94ebbd < 7e043a80b5dae5c2d2cf84031501de7827fd6c00 | 7e043a80b5dae5c2d2cf84031501de7827fd6c00 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 5.13 < 6.0.10 | 6.0.10 |
| msrc | cbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0 | — | — |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Microsoft
netfs: Fix missing xas_retry() calls in xarray iteration
vendor_msrc·2025-05-13·CVSS 5.5
CVE-2022-49810 [MEDIUM] CWE-476 netfs: Fix missing xas_retry() calls in xarray iteration
netfs: Fix missing xas_retry() calls in xarray iteration
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Red Hat
kernel: netfs: Fix missing xas_retry() calls in xarray iteration
vendor_redhat·2025-05-01·CVSS 5.5
CVE-2022-49810 [MEDIUM] kernel: netfs: Fix missing xas_retry() calls in xarray iteration
kernel: netfs: Fix missing xas_retry() calls in xarray iteration
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing xas_retry() calls in xarray iteration
netfslib has a number of places in which it performs iteration of an xarray
whilst being under the RCU read lock. It *should* call xas_retry() as the
first thing inside of the loop and do "continue" if it returns true in case
the xarray walker passed out a special value indicating that the walk needs
to be redone from the root[*].
Fix this by adding the missing retry checks.
[*] I wonder if this should be done inside xas_find(), xas_next_node() and
suchlike, but I'm told that's not an simple change to effect.
This can cause an oops like that below. Note the faulting address - this
is an internal value
Debian
CVE-2022-49810: linux - In the Linux kernel, the following vulnerability has been resolved: netfs: Fix ...
vendor_debian·2022·CVSS 5.5
CVE-2022-49810 [MEDIUM] CVE-2022-49810: linux - In the Linux kernel, the following vulnerability has been resolved: netfs: Fix ...
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing xas_retry() calls in xarray iteration netfslib has a number of places in which it performs iteration of an xarray whilst being under the RCU read lock. It *should* call xas_retry() as the first thing inside of the loop and do "continue" if it returns true in case the xarray walker passed out a special value indicating that the walk needs to be redone from the root[*]. Fix this by adding the missing retry checks. [*] I wonder if this should be done inside xas_find(), xas_next_node() and suchlike, but I'm told that's not an simple change to effect. This can cause an oops like that below. Note the faulting address - this is an internal value (|0x2) returned from xarray. BUG: kernel NULL pointer dereference,
GHSA
GHSA-5qqg-7vmr-gjg2: In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing xas_retry() calls in xarray iteration
netfslib has a number o
ghsa_unreviewed·2025-05-01
CVE-2022-49810 [MEDIUM] CWE-476 GHSA-5qqg-7vmr-gjg2: In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing xas_retry() calls in xarray iteration
netfslib has a number o
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing xas_retry() calls in xarray iteration
netfslib has a number of places in which it performs iteration of an xarray
whilst being under the RCU read lock. It *should* call xas_retry() as the
first thing inside of the loop and do "continue" if it returns true in case
the xarray walker passed out a special value indicating that the walk needs
to be redone from the root[*].
Fix this by adding the missing retry checks.
[*] I wonder if this should be done inside xas_find(), xas_next_node() and
suchlike, but I'm told that's not an simple change to effect.
This can cause an oops like that below. Note the faulting address - this
is an internal value (|0x2) returned from xarray.
BUG: kernel NULL pointer derefe
OSV
CVE-2022-49810: In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing xas_retry() calls in xarray iteration netfslib has a number of
osv·2025-05-01·CVSS 5.5
CVE-2022-49810 [MEDIUM] CVE-2022-49810: In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing xas_retry() calls in xarray iteration netfslib has a number of
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing xas_retry() calls in xarray iteration netfslib has a number of places in which it performs iteration of an xarray whilst being under the RCU read lock. It *should* call xas_retry() as the first thing inside of the loop and do "continue" if it returns true in case the xarray walker passed out a special value indicating that the walk needs to be redone from the root[*]. Fix this by adding the missing retry checks. [*] I wonder if this should be done inside xas_find(), xas_next_node() and suchlike, but I'm told that's not an simple change to effect. This can cause an oops like that below. Note the faulting address - this is an internal value (|0x2) returned from xarray. BUG: kernel NULL pointer dereference,
No detection rules found.
No public exploits indexed.
2025-05-01
Published