CVE-2022-48847
published 2024-07-16CVE-2022-48847: In the Linux kernel, the following vulnerability has been resolved: watch_queue: Fix filter limit check In watch_queue_set_filter(), there are a couple of…
PriorityP338high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.24%
15.1th percentile
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Fix filter limit check
In watch_queue_set_filter(), there are a couple of places where we check
that the filter type value does not exceed what the type_filter bitmap
can hold. One place calculates the number of bits by:
if (tf[i].type >= sizeof(wfilter->type_filter) * 8)
which is fine, but the second does:
if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)
which is not. This can lead to a couple of out-of-bounds writes due to
a too-large type:
(1) __set_bit() on wfilter->type_filter
(2) Writing more elements in wfilter->filters[] than we allocated.
Fix this by just using the proper WATCH_TYPE__NR instead, which is the
number of types we actually know about.
The bug may cause an oops looking something like:
BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740
Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611
...
Call Trace:
dump_stack_lvl+0x45/0x59
print_address_description.constprop.0+0x1f/0x150
...
kasan_report.cold+0x7f/0x11b
...
watch_queue_set_filter+0x659/0x740
...
__x64_sys_ioctl+0x127/0x190
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
Allocated by task 611:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x81/0xa0
watch_queue_set_filter+0x23a/0x740
__x64_sys_ioctl+0x127/0x190
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88800d2c66a0
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 28 bytes inside of
32-byte region [ffff88800d2c66a0, ffff88800d2c66c0)
Affected
13 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.16.18-1 (bookworm) | linux 5.16.18-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= c73be61cede5882f9605a852414db559c0ebedfd < 648895da69ced90ca770fd941c3d9479a9d72c16 | 648895da69ced90ca770fd941c3d9479a9d72c16 |
| linux | linux | >= c73be61cede5882f9605a852414db559c0ebedfd < 1b09f28f70a5046acd64138075ae3f095238b045 | 1b09f28f70a5046acd64138075ae3f095238b045 |
| linux | linux | >= c73be61cede5882f9605a852414db559c0ebedfd < b36588ebbcef74583824c08352e75838d6fb4ff2 | b36588ebbcef74583824c08352e75838d6fb4ff2 |
| linux | linux | >= c73be61cede5882f9605a852414db559c0ebedfd < c993ee0f9f81caf5767a50d1faeba39a0dc82af2 | c993ee0f9f81caf5767a50d1faeba39a0dc82af2 |
| linux | linux_kernel | >= 0 < 5.10.106-1 | 5.10.106-1 |
| linux | linux_kernel | >= 0 < 5.16.18-1 | 5.16.18-1 |
| linux | linux_kernel | >= 0 < 5.16.18-1 | 5.16.18-1 |
| linux | linux_kernel | >= 0 < 5.16.18-1 | 5.16.18-1 |
| linux | linux_kernel | >= 5.11 < 5.15.29 | 5.15.29 |
| linux | linux_kernel | >= 5.16 < 5.16.15 | 5.16.15 |
| linux | linux_kernel | >= 5.8 < 5.10.106 | 5.10.106 |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8HIGH
vendor_redhat7.8HIGH
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.
GHSA
GHSA-wgcq-m83r-f344: In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Fix filter limit check
In watch_queue_set_filter(), there are a cou
ghsa_unreviewed·2024-07-16
CVE-2022-48847 [HIGH] CWE-787 GHSA-wgcq-m83r-f344: In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Fix filter limit check
In watch_queue_set_filter(), there are a cou
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Fix filter limit check
In watch_queue_set_filter(), there are a couple of places where we check
that the filter type value does not exceed what the type_filter bitmap
can hold. One place calculates the number of bits by:
if (tf[i].type >= sizeof(wfilter->type_filter) * 8)
which is fine, but the second does:
if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)
which is not. This can lead to a couple of out-of-bounds writes due to
a too-large type:
(1) __set_bit() on wfilter->type_filter
(2) Writing more elements in wfilter->filters[] than we allocated.
Fix this by just using the proper WATCH_TYPE__NR instead, which is the
number of types we actually know about.
The bug may cause an oops look
OSV
CVE-2022-48847: In the Linux kernel, the following vulnerability has been resolved: watch_queue: Fix filter limit check In watch_queue_set_filter(), there are a coupl
osv·2024-07-16·CVSS 7.8
CVE-2022-48847 [HIGH] CVE-2022-48847: In the Linux kernel, the following vulnerability has been resolved: watch_queue: Fix filter limit check In watch_queue_set_filter(), there are a coupl
In the Linux kernel, the following vulnerability has been resolved: watch_queue: Fix filter limit check In watch_queue_set_filter(), there are a couple of places where we check that the filter type value does not exceed what the type_filter bitmap can hold. One place calculates the number of bits by: if (tf[i].type >= sizeof(wfilter->type_filter) * 8) which is fine, but the second does: if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG) which is not. This can lead to a couple of out-of-bounds writes due to a too-large type: (1) __set_bit() on wfilter->type_filter (2) Writing more elements in wfilter->filters[] than we allocated. Fix this by just using the proper WATCH_TYPE__NR instead, which is the number of types we actually know about. The bug may cause an oops looking somet
Red Hat
kernel: watch_queue: Fix filter limit check
vendor_redhat·2024-07-16·CVSS 7.8
CVE-2022-48847 [HIGH] CWE-125 kernel: watch_queue: Fix filter limit check
kernel: watch_queue: Fix filter limit check
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Fix filter limit check
In watch_queue_set_filter(), there are a couple of places where we check
that the filter type value does not exceed what the type_filter bitmap
can hold. One place calculates the number of bits by:
if (tf[i].type >= sizeof(wfilter->type_filter) * 8)
which is fine, but the second does:
if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)
which is not. This can lead to a couple of out-of-bounds writes due to
a too-large type:
(1) __set_bit() on wfilter->type_filter
(2) Writing more elements in wfilter->filters[] than we allocated.
Fix this by just using the proper WATCH_TYPE__NR instead, which is the
number of types we actually know a
Debian
CVE-2022-48847: linux - In the Linux kernel, the following vulnerability has been resolved: watch_queue...
vendor_debian·2022·CVSS 7.8
CVE-2022-48847 [HIGH] CVE-2022-48847: linux - In the Linux kernel, the following vulnerability has been resolved: watch_queue...
In the Linux kernel, the following vulnerability has been resolved: watch_queue: Fix filter limit check In watch_queue_set_filter(), there are a couple of places where we check that the filter type value does not exceed what the type_filter bitmap can hold. One place calculates the number of bits by: if (tf[i].type >= sizeof(wfilter->type_filter) * 8) which is fine, but the second does: if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG) which is not. This can lead to a couple of out-of-bounds writes due to a too-large type: (1) __set_bit() on wfilter->type_filter (2) Writing more elements in wfilter->filters[] than we allocated. Fix this by just using the proper WATCH_TYPE__NR instead, which is the number of types we actually know about. The bug may cause an oops looking somet
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2https://git.kernel.org/stable/c/c993ee0f9f81caf5767a50d1faeba39a0dc82af2https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2https://git.kernel.org/stable/c/c993ee0f9f81caf5767a50d1faeba39a0dc82af2
2024-07-16
Published