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:
<TASK>
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)
Security readout for executives and security teams
Plain-English summary
CVE-2022-48847 is a Linux kernel watch_queue bug where an incorrect filter limit check can write past allocated memory. The provided evidence shows kernel out-of-bounds writes and a possible kernel oops. No CVSS score, CWE, or active exploitation evidence is provided.
Executive priority
Patch through the normal kernel update program, with higher priority for shared, multi-user, or high-availability Linux systems. Urgency is moderated by missing CVSS data and no cited exploitation, but kernel memory corruption can still create operational risk.
Technical view
watch_queue_set_filter() used an incorrect size calculation for type_filter in one check, allowing an oversized filter type. The Linux fix changes validation to use WATCH_TYPE__NR, preventing __set_bit() and filters[] out-of-bounds writes. The source trace shows the issue reachable through an ioctl path.
Likely exposure
Exposure is limited to Linux systems running affected kernel versions or downstream builds containing the vulnerable watch_queue code before the referenced stable fixes. The bundle lists Linux 5.8 and affected stable ranges ending around 5.10.106, 5.15.29, 5.16.15, and 5.17, but downstream vendor backports must be verified.
Exploitation context
The source bundle does not report public exploitation, weaponized proof of concept, or CISA KEV listing. The demonstrated impact is a KASAN-detected slab out-of-bounds write and possible kernel oops. Treat exploitability beyond crash or memory corruption as unconfirmed from these sources.
Researcher notes
Key evidence is the upstream Linux fix rationale: two out-of-bounds writes caused by a filter type limit mismatch. The bundle does not provide a CVSS vector, affected distro matrix, exploit primitives, or confirmed security impact beyond KASAN out-of-bounds write and oops evidence.
Mitigation direction
Upgrade to a vendor kernel containing the referenced stable watch_queue fixes.
Verify distribution advisories because vendors may backport fixes without changing kernel version strings.
Prioritize internet-facing or multi-user Linux hosts after confirming they run affected kernels.
If no vendor package is available, follow official Linux distribution mitigation guidance.
Validation and detection
Inventory Linux kernel versions across servers, containers hosts, appliances, and cloud images.
Check vendor changelogs for the referenced stable commit IDs or CVE-2022-48847.
Confirm whether watch_queue support exists in the deployed kernel configuration.
Run regression testing before broad kernel rollout on production-critical hosts.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-48847 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.