CVE-2022-48847: linux kernel Memory Corruption — Fix

Description

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)

Is your site exposed to CVE-2022-48847?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

7.8

HIGH

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Weakness Type (CWE)

CWE-787 Out-of-bounds Write

Affected Products

Vendor	Product	Versions
linux	linux_kernel	5.8 — 5.10.106
linux	linux_kernel	5.11 — 5.15.29
linux	linux_kernel	5.16 — 5.16.15

References

Advisories & Patches

https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045 https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16 https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2 https://git.kernel.org/stable/c/c993ee0f9f81caf5767a50d1faeba39a0dc82af2 https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045 https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16 https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2 https://git.kernel.org/stable/c/c993ee0f9f81caf5767a50d1faeba39a0dc82af2

Frequently Asked Questions

What is 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 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) It has a CVSS v3.1 base score of 7.8 (HIGH).

How severe is CVE-2022-48847? +

CVE-2022-48847 has a CVSS v3.1 score of 7.8 out of 10, rated HIGH. This is a high-severity vulnerability that should be prioritized for patching.

What products are affected by CVE-2022-48847? +

CVE-2022-48847 affects products from linux, specifically: linux_kernel. Check the affected products table above for specific version ranges.

How do I check if I'm vulnerable to CVE-2022-48847? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-8358

LibreOffice Calc can import tracked changes from a spreadsheet document. A heap buffer overflow existed when a document reused the …

CVE-2026-8356

LibreOffice can import presentations in the legacy binary PPT format. A stack buffer overflow existed when importing a colour-replacement record. …

CVE-2026-6040

A heap use-after-free existed when importing the blank-width characters of an ODF number format. A position value read from the …

CVE-2026-6039

LibreOffice can import drawings in the DXF format used by CAD software. A heap buffer overflow existed when importing a …

CVE-2026-3298

The method "sock_recvfrom_into()" of "asyncio.ProacterEventLoop" (Windows only) was missing a boundary check for the data buffer when using nbytes parameter. …

CVE-2026-40489

editorconfig-core-c is an EditorConfig core library for use by plugins supporting EditorConfig parsing. Versions up to and including 0.12.10 have …

CVE-2022-48847