https://vulnerability.circl.lu/rss/recent/all/10 Most recent entries from all 2026-09-28T14:13:49.976984+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://vulnerability.circl.lu/vuln/bell-cve-2026-89953 BELL-CVE-2026-89953 2026-09-28T14:13:54.271927+00:00

Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

 https://vulnerability.circl.lu/vuln/fkie_cve-2026-89953 fkie_cve-2026-89953 2026-09-28T14:13:54.272031+00:00

In the Linux kernel, the following vulnerability has been resolved:

mtd: mtdoops: free page bitmap when the backing MTD is removed

mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle.

This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it.

Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.

 https://vulnerability.circl.lu/vuln/ghsa-wvj7-v5wh-67w6 GHSA-wvj7-v5wh-67w6 2026-09-28T14:13:54.272109+00:00

In the Linux kernel, the following vulnerability has been resolved:

mtd: mtdoops: free page bitmap when the backing MTD is removed

mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle.

This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it.

Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.

 https://vulnerability.circl.lu/vuln/msrc_cve-2026-89953 msrc_CVE-2026-89953 — mtd: mtdoops: free page bitmap when the backing MTD is removed 2026-09-28T14:13:54.272155+00:00 msrc_CVE-2026-89953 https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1 openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media 2026-09-28T14:13:54.272192+00:00

kernel-devel-7.2.7-1.1 on GA media

 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-89953 UBUNTU-CVE-2026-89953 2026-09-28T14:13:54.273303+00:00

Affected: Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more

In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.