{"vulnerability": "cve-2024-5788", "sightings": [{"uuid": "320e50a8-39a7-4195-b4d9-06ecdbbb870f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57880", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113810360720791001", "content": "", "creation_timestamp": "2025-01-11T15:11:27.882726Z"}, {"uuid": "b3aa44c6-06d0-4170-bb73-7c36bdf47084", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57880", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfhyryjsqq2e", "content": "", "creation_timestamp": "2025-01-11T15:15:53.951193Z"}, {"uuid": "e0fb99b8-253e-4b60-a264-3a3ef6dc40c3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57881", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113810399757862515", "content": "", "creation_timestamp": "2025-01-11T15:21:23.469101Z"}, {"uuid": "46ea3e6f-6537-429b-94c0-144f0aaf270e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57880", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lfi245jwer2h", "content": "", "creation_timestamp": "2025-01-11T15:39:30.044441Z"}, {"uuid": "ae850cc1-cc63-4c7e-b531-e59d4f70e986", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57881", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfi44yfuwr22", "content": "", "creation_timestamp": "2025-01-11T16:15:43.739695Z"}, {"uuid": "e74f2538-9356-4a3a-8ac5-8e0a052cb87b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57881", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lfi6amskr42g", "content": "", "creation_timestamp": "2025-01-11T16:53:33.296629Z"}, {"uuid": "5befb98d-5e2a-4498-8fb5-2b653f7449ea", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57881", "type": "seen", "source": "https://bsky.app/profile/omo.bsky.social/post/3lfmexmah2k2d", "content": "", "creation_timestamp": "2025-01-13T09:04:27.825311Z"}, {"uuid": "9fa9deec-c06c-4b54-a85f-5199ebdf0c4a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57886", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfrtyh4uxb2b", "content": "", "creation_timestamp": "2025-01-15T13:16:38.860134Z"}, {"uuid": "a2c3f0d8-0345-495b-965f-8725636677f9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57882", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfrty5n2652t", "content": "", "creation_timestamp": "2025-01-15T13:16:29.250145Z"}, {"uuid": "7be1b3b2-d5bc-447a-b7eb-f13073f74492", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57888", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfrtylvy7y2n", "content": "", "creation_timestamp": "2025-01-15T13:16:43.918852Z"}, {"uuid": "8421ebbd-c2a1-4d01-8a73-a35d6664e980", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57884", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfrtyc4nkh2n", "content": "", "creation_timestamp": "2025-01-15T13:16:33.621885Z"}, {"uuid": "07c35803-5012-429e-ab96-d016e7cb57d1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57887", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfrtyjnolo2r", "content": "", "creation_timestamp": "2025-01-15T13:16:41.532828Z"}, {"uuid": "900683b1-dd64-4ffa-b126-dc233d027f36", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57883", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfrty7vuo62t", "content": "", "creation_timestamp": "2025-01-15T13:16:31.322009Z"}, {"uuid": "4e27c9e5-eece-4eff-9360-cbfe633e34ae", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57885", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfrtyevti22j", "content": "", "creation_timestamp": "2025-01-15T13:16:36.493973Z"}, {"uuid": "c28b4ece-f3f2-4dfe-b775-50f8d2877106", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57889", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfrtyod23z2c", "content": "", "creation_timestamp": "2025-01-15T13:16:46.317588Z"}, {"uuid": "a78be379-8be9-4ceb-990b-baf2d54a1c3f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57887", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lfrvq7fzpz2w", "content": "", "creation_timestamp": "2025-01-15T13:47:52.497975Z"}, {"uuid": "89a7171e-16ba-4132-8ed1-a9783b944c53", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57882", "type": "seen", "source": "https://bsky.app/profile/buherator.bsky.social/post/3llrm5goqas25", "content": "", "creation_timestamp": "2025-04-01T19:27:26.528941Z"}, {"uuid": "47a532e7-3e94-4013-92e0-57087a8155e5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57882", "type": "seen", "source": "https://bsky.app/profile/infosec.skyfleet.blue/post/3llrelgootz26", "content": "", "creation_timestamp": "2025-04-01T17:12:06.224279Z"}, {"uuid": "35bf14db-6b4d-42be-a5f7-693b07a3f570", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57882", "type": "seen", "source": "https://bsky.app/profile/infosec.skyfleet.blue/post/3llrjdld3c22k", "content": "", "creation_timestamp": "2025-04-01T18:37:10.954519Z"}, {"uuid": "630193c1-fc1d-4eb8-8843-cf9cfd46a8ae", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57882", "type": "seen", "source": "https://infosec.exchange/users/andersonc0d3/statuses/114264166030412462", "content": "", "creation_timestamp": "2025-04-01T18:40:07.508351Z"}, {"uuid": "be6229ae-586b-4c07-a24c-c8e2b78989f4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57882", "type": "seen", "source": "https://bsky.app/profile/buherator.bsky.social/post/3llrfwedg2q25", "content": "", "creation_timestamp": "2025-04-01T17:36:06.676233Z"}, {"uuid": "7ae1da53-dff9-490b-9c51-93b7856ed39e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57882", "type": "seen", "source": "https://infosec.exchange/users/andersonc0d3/statuses/114264166030412462", "content": "", "creation_timestamp": "2025-04-01T18:40:07.516217Z"}, {"uuid": "f8e34878-a6ec-4b0a-8153-4bc80d0b0d8d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57882", "type": "seen", "source": "https://bsky.app/profile/andersonc0d3.bsky.social/post/3llrjir6fmc2u", "content": "", "creation_timestamp": "2025-04-01T18:40:10.545214Z"}, {"uuid": "eec166c1-a166-421e-bcb1-635e64e1df8c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-57887", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "527b4f0a-e34b-440b-b25c-e36e2961dba8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-57888", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "39b71990-b957-465c-8301-a8a7d0474e87", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-57887", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "1c7b0048-0932-4e7d-884f-ef30c2ca0eda", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-57883", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "393fe257-8026-4269-bd32-e6b32e9ca18c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-57888", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "0f1125b4-e9f4-4841-9829-75cb8d5320a4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57889", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/1757", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57889\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking\n\nIf a device uses MCP23xxx IO expander to receive IRQs, the following\nbug can happen:\n\n  BUG: sleeping function called from invalid context\n    at kernel/locking/mutex.c:283\n  in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ...\n  preempt_count: 1, expected: 0\n  ...\n  Call Trace:\n  ...\n  __might_resched+0x104/0x10e\n  __might_sleep+0x3e/0x62\n  mutex_lock+0x20/0x4c\n  regmap_lock_mutex+0x10/0x18\n  regmap_update_bits_base+0x2c/0x66\n  mcp23s08_irq_set_type+0x1ae/0x1d6\n  __irq_set_trigger+0x56/0x172\n  __setup_irq+0x1e6/0x646\n  request_threaded_irq+0xb6/0x160\n  ...\n\nWe observed the problem while experimenting with a touchscreen driver which\nused MCP23017 IO expander (I2C).\n\nThe regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from\nconcurrent accesses, which is the default for regmaps without .fast_io,\n.disable_locking, etc.\n\nmcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter\nlocks the mutex.\n\nHowever, __setup_irq() locks desc-&gt;lock spinlock before calling these\nfunctions. As a result, the system tries to lock the mutex whole holding\nthe spinlock.\n\nIt seems, the internal regmap locks are not needed in this driver at all.\nmcp-&gt;lock seems to protect the regmap from concurrent accesses already,\nexcept, probably, in mcp_pinconf_get/set.\n\nmcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under\nchip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes\nmcp-&gt;lock and enables regmap caching, so that the potentially slow I2C\naccesses are deferred until chip_bus_unlock().\n\nThe accesses to the regmap from mcp23s08_probe_one() do not need additional\nlocking.\n\nIn all remaining places where the regmap is accessed, except\nmcp_pinconf_get/set(), the driver already takes mcp-&gt;lock.\n\nThis patch adds locking in mcp_pinconf_get/set() and disables internal\nlocking in the regmap config. Among other things, it fixes the sleeping\nin atomic context described above.\n\ud83d\udccf Published: 2025-01-15T13:05:41.769Z\n\ud83d\udccf Modified: 2025-01-15T13:05:41.769Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/788d9e9a41b81893d6bb8faa05f045c975278318\n2. https://git.kernel.org/stable/c/c55d186376a87b468c9ee30f2195e0f3857f61a0\n3. https://git.kernel.org/stable/c/9372e160d8211a7e17f2abff8370794f182df785\n4. https://git.kernel.org/stable/c/0310cbad163a908d09d99c26827859365cd71fcb\n5. https://git.kernel.org/stable/c/8c6fd5803b988a5e78c9b9e42c70a936d7cfc6ec\n6. https://git.kernel.org/stable/c/830f838589522404cd7c2f0f540602f25034af61\n7. https://git.kernel.org/stable/c/a37eecb705f33726f1fb7cd2a67e514a15dfe693", "creation_timestamp": "2025-01-15T14:27:23.000000Z"}, {"uuid": "1c8e2fa5-8b05-4011-9bbe-e949e6637aaf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57883", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2122", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57883\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nmm: hugetlb: independent PMD page table shared count\n\nThe folio refcount may be increased unexpectly through try_get_folio() by\ncaller such as split_huge_pages.  In huge_pmd_unshare(), we use refcount\nto check whether a pmd page table is shared.  The check is incorrect if\nthe refcount is increased by the above caller, and this can cause the page\ntable leaked:\n\n BUG: Bad page state in process sh  pfn:109324\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324\n flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff)\n page_type: f2(table)\n raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000\n raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000\n page dumped because: nonzero mapcount\n ...\n CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G    B              6.13.0-rc2master+ #7\n Tainted: [B]=BAD_PAGE\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n Call trace:\n  show_stack+0x20/0x38 (C)\n  dump_stack_lvl+0x80/0xf8\n  dump_stack+0x18/0x28\n  bad_page+0x8c/0x130\n  free_page_is_bad_report+0xa4/0xb0\n  free_unref_page+0x3cc/0x620\n  __folio_put+0xf4/0x158\n  split_huge_pages_all+0x1e0/0x3e8\n  split_huge_pages_write+0x25c/0x2d8\n  full_proxy_write+0x64/0xd8\n  vfs_write+0xcc/0x280\n  ksys_write+0x70/0x110\n  __arm64_sys_write+0x24/0x38\n  invoke_syscall+0x50/0x120\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x34/0x128\n  el0t_64_sync_handler+0xc8/0xd0\n  el0t_64_sync+0x190/0x198\n\nThe issue may be triggered by damon, offline_page, page_idle, etc, which\nwill increase the refcount of page table.\n\n1. The page table itself will be discarded after reporting the\n   \"nonzero mapcount\".\n\n2. The HugeTLB page mapped by the page table miss freeing since we\n   treat the page table as shared and a shared page table will not be\n   unmapped.\n\nFix it by introducing independent PMD page table shared count.  As\ndescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390\ngmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv\npmds, so we can reuse the field as pt_share_count.\n\ud83d\udccf Published: 2025-01-15T13:05:36.352Z\n\ud83d\udccf Modified: 2025-01-17T13:27:06.115Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/56b274473d6e7e7375f2d0a2b4aca11d67c6b52f\n2. https://git.kernel.org/stable/c/2e31443a0d18ae43b9d29e02bf0563f07772193d\n3. https://git.kernel.org/stable/c/59d9094df3d79443937add8700b2ef1a866b1081", "creation_timestamp": "2025-01-17T13:56:44.000000Z"}, {"uuid": "f2a26977-7671-4bda-8b57-369e3d6a2edd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57887", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2121", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57887\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: adv7511: Fix use-after-free in adv7533_attach_dsi()\n\nThe host_node pointer was assigned and freed in adv7533_parse_dt(), and\nlater, adv7533_attach_dsi() uses the same. Fix this use-after-free issue\nby\u00a0dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()\nin error path of probe() and also in the remove().\n\ud83d\udccf Published: 2025-01-15T13:05:39.933Z\n\ud83d\udccf Modified: 2025-01-17T13:27:07.276Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/d208571943ffddc438a7ce533d5d0b9219806242\n2. https://git.kernel.org/stable/c/1f49aaf55652580ae63ab83d67211fe6a55d83dc\n3. https://git.kernel.org/stable/c/ca9d077350fa21897de8bf64cba23b198740aab5\n4. https://git.kernel.org/stable/c/81adbd3ff21c1182e06aa02c6be0bfd9ea02d8e8", "creation_timestamp": "2025-01-17T13:56:43.000000Z"}, {"uuid": "bb9a9c97-8513-438c-82b8-b3e271f8e803", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57883", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/19690", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57883\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nmm: hugetlb: independent PMD page table shared count\n\nThe folio refcount may be increased unexpectly through try_get_folio() by\ncaller such as split_huge_pages.  In huge_pmd_unshare(), we use refcount\nto check whether a pmd page table is shared.  The check is incorrect if\nthe refcount is increased by the above caller, and this can cause the page\ntable leaked:\n\n BUG: Bad page state in process sh  pfn:109324\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324\n flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff)\n page_type: f2(table)\n raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000\n raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000\n page dumped because: nonzero mapcount\n ...\n CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G    B              6.13.0-rc2master+ #7\n Tainted: [B]=BAD_PAGE\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n Call trace:\n  show_stack+0x20/0x38 (C)\n  dump_stack_lvl+0x80/0xf8\n  dump_stack+0x18/0x28\n  bad_page+0x8c/0x130\n  free_page_is_bad_report+0xa4/0xb0\n  free_unref_page+0x3cc/0x620\n  __folio_put+0xf4/0x158\n  split_huge_pages_all+0x1e0/0x3e8\n  split_huge_pages_write+0x25c/0x2d8\n  full_proxy_write+0x64/0xd8\n  vfs_write+0xcc/0x280\n  ksys_write+0x70/0x110\n  __arm64_sys_write+0x24/0x38\n  invoke_syscall+0x50/0x120\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x34/0x128\n  el0t_64_sync_handler+0xc8/0xd0\n  el0t_64_sync+0x190/0x198\n\nThe issue may be triggered by damon, offline_page, page_idle, etc, which\nwill increase the refcount of page table.\n\n1. The page table itself will be discarded after reporting the\n   \"nonzero mapcount\".\n\n2. The HugeTLB page mapped by the page table miss freeing since we\n   treat the page table as shared and a shared page table will not be\n   unmapped.\n\nFix it by introducing independent PMD page table shared count.  As\ndescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390\ngmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv\npmds, so we can reuse the field as pt_share_count.\n\ud83d\udccf Published: 2025-01-15T13:05:36.352Z\n\ud83d\udccf Modified: 2025-06-27T10:21:12.793Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/94b4b41d0cdf5cfd4d4325bc0e6e9e0d0e996133\n2. https://git.kernel.org/stable/c/8410996eb6fea116fe1483ed977aacf580eee7b4\n3. https://git.kernel.org/stable/c/02333ac1c35370517a19a4a131332a9690c6a5c7\n4. https://git.kernel.org/stable/c/56b274473d6e7e7375f2d0a2b4aca11d67c6b52f\n5. https://git.kernel.org/stable/c/2e31443a0d18ae43b9d29e02bf0563f07772193d\n6. https://git.kernel.org/stable/c/59d9094df3d79443937add8700b2ef1a866b1081", "creation_timestamp": "2025-06-27T10:49:56.000000Z"}, {"uuid": "6e46ad47-0c84-4d6a-913c-12738fd85880", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57889", "type": "seen", "source": "https://t.me/cvedetector/15455", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57889 - Linux Kernel PineA64 Pinctrl regmap(mutex)\", \n  \"Content\": \"CVE ID : CVE-2024-57889 \nPublished : Jan. 15, 2025, 1:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking  \n  \nIf a device uses MCP23xxx IO expander to receive IRQs, the following  \nbug can happen:  \n  \n  BUG: sleeping function called from invalid context  \n    at kernel/locking/mutex.c:283  \n  in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ...  \n  preempt_count: 1, expected: 0  \n  ...  \n  Call Trace:  \n  ...  \n  __might_resched+0x104/0x10e  \n  __might_sleep+0x3e/0x62  \n  mutex_lock+0x20/0x4c  \n  regmap_lock_mutex+0x10/0x18  \n  regmap_update_bits_base+0x2c/0x66  \n  mcp23s08_irq_set_type+0x1ae/0x1d6  \n  __irq_set_trigger+0x56/0x172  \n  __setup_irq+0x1e6/0x646  \n  request_threaded_irq+0xb6/0x160  \n  ...  \n  \nWe observed the problem while experimenting with a touchscreen driver which  \nused MCP23017 IO expander (I2C).  \n  \nThe regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from  \nconcurrent accesses, which is the default for regmaps without .fast_io,  \n.disable_locking, etc.  \n  \nmcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter  \nlocks the mutex.  \n  \nHowever, __setup_irq() locks desc-&gt;lock spinlock before calling these  \nfunctions. As a result, the system tries to lock the mutex whole holding  \nthe spinlock.  \n  \nIt seems, the internal regmap locks are not needed in this driver at all.  \nmcp-&gt;lock seems to protect the regmap from concurrent accesses already,  \nexcept, probably, in mcp_pinconf_get/set.  \n  \nmcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under  \nchip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes  \nmcp-&gt;lock and enables regmap caching, so that the potentially slow I2C  \naccesses are deferred until chip_bus_unlock().  \n  \nThe accesses to the regmap from mcp23s08_probe_one() do not need additional  \nlocking.  \n  \nIn all remaining places where the regmap is accessed, except  \nmcp_pinconf_get/set(), the driver already takes mcp-&gt;lock.  \n  \nThis patch adds locking in mcp_pinconf_get/set() and disables internal  \nlocking in the regmap config. Among other things, it fixes the sleeping  \nin atomic context described above. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"15 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-15T15:07:02.000000Z"}, {"uuid": "8f4f3b11-16b3-4b61-96ca-3bee25a1b46c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57887", "type": "seen", "source": "https://t.me/cvedetector/15454", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57887 - Linux Kernelony Use-After-Free Vulnerability in Adv7511 DRM\", \n  \"Content\": \"CVE ID : CVE-2024-57887 \nPublished : Jan. 15, 2025, 1:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm: adv7511: Fix use-after-free in adv7533_attach_dsi()  \n  \nThe host_node pointer was assigned and freed in adv7533_parse_dt(), and  \nlater, adv7533_attach_dsi() uses the same. Fix this use-after-free issue  \nby\u00a0dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()  \nin error path of probe() and also in the remove(). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"15 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-15T15:06:58.000000Z"}, {"uuid": "b756298d-6840-44c3-89a4-ab2f1516392e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57886", "type": "seen", "source": "https://t.me/cvedetector/15461", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57886 - Linux Kernel DAMON Memory Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-57886 \nPublished : Jan. 15, 2025, 1:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/damon/core: fix new damon_target objects leaks on damon_commit_targets()  \n  \nPatch series \"mm/damon/core: fix memory leaks and ignored inputs from  \ndamon_commit_ctx()\".  \n  \nDue to two bugs in damon_commit_targets() and damon_commit_schemes(),  \nwhich are called from damon_commit_ctx(), some user inputs can be ignored,  \nand some mmeory objects can be leaked.  Fix those.  \n  \nNote that only DAMON sysfs interface users are affected.  Other DAMON core  \nAPI user modules that more focused more on simple and dedicated production  \nusages, including DAMON_RECLAIM and DAMON_LRU_SORT are not using the buggy  \nfunction in the way, so not affected.  \n  \n  \nThis patch (of 2):  \n  \nWhen new DAMON targets are added via damon_commit_targets(), the newly  \ncreated targets are not deallocated when updating the internal data  \n(damon_commit_target()) is failed.  Worse yet, even if the setup is  \nsuccessfully done, the new target is not linked to the context.  Hence,  \nthe new targets are always leaked regardless of the internal data setup  \nfailure.  Fix the leaks. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"15 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-15T15:07:41.000000Z"}, {"uuid": "fbe11701-ee4c-4122-99d9-1454fff41ebf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57888", "type": "seen", "source": "https://t.me/cvedetector/15456", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57888 - \"AMDGPU Workqueue Memory Reclaim False Positive Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-57888 \nPublished : Jan. 15, 2025, 1:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nworkqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker  \n  \nAfter commit  \n746ae46c1113 (\"drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM\")  \namdgpu started seeing the following warning:  \n  \n [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]  \n...  \n [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]  \n...  \n [ ] Call Trace:  \n [ ]    \n...  \n [ ]  ? check_flush_dependency+0xf5/0x110  \n...  \n [ ]  cancel_delayed_work_sync+0x6e/0x80  \n [ ]  amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu]  \n [ ]  amdgpu_ring_alloc+0x40/0x50 [amdgpu]  \n [ ]  amdgpu_ib_schedule+0xf4/0x810 [amdgpu]  \n [ ]  ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched]  \n [ ]  amdgpu_job_run+0xaa/0x1f0 [amdgpu]  \n [ ]  drm_sched_run_job_work+0x257/0x430 [gpu_sched]  \n [ ]  process_one_work+0x217/0x720  \n...  \n [ ]    \n  \nThe intent of the verifcation done in check_flush_depedency is to ensure  \nforward progress during memory reclaim, by flagging cases when either a  \nmemory reclaim process, or a memory reclaim work item is flushed from a  \ncontext not marked as memory reclaim safe.  \n  \nThis is correct when flushing, but when called from the  \ncancel(_delayed)_work_sync() paths it is a false positive because work is  \neither already running, or will not be running at all. Therefore  \ncancelling it is safe and we can relax the warning criteria by letting the  \nhelper know of the calling context.  \n  \nReferences: 746ae46c1113 (\"drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM\") \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"15 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-15T15:07:03.000000Z"}, {"uuid": "79ea1a42-b2de-493a-b4a9-056874717eec", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57881", "type": "seen", "source": "https://t.me/cvedetector/15098", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57881 - Linux Kernel \"pfn_to_page\" NULL Pointer Dereference Vulnerability in Buddy Allocator\", \n  \"Content\": \"CVE ID : CVE-2024-57881 \nPublished : Jan. 11, 2025, 4:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()  \n  \nIn split_large_buddy(), we might call pfn_to_page() on a PFN that might  \nnot exist.  In corner cases, such as when freeing the highest pageblock in  \nthe last memory section, this could result with CONFIG_SPARSEMEM &amp;&amp;  \n!CONFIG_SPARSEMEM_EXTREME in __pfn_to_section() returning NULL and and  \n__section_mem_map_addr() dereferencing that NULL pointer.  \n  \nLet's fix it, and avoid doing a pfn_to_page() call for the first  \niteration, where we already have the page.  \n  \nSo far this was found by code inspection, but let's just CC stable as the  \nfix is easy. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-11T18:16:56.000000Z"}, {"uuid": "44b6359f-bfe9-449e-9a95-768762c56ae3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57880", "type": "seen", "source": "https://t.me/cvedetector/15088", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57880 - Intel ASoC SOF SDW Array Index Out-of-Bounds Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-57880 \nPublished : Jan. 11, 2025, 3:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nASoC: Intel: sof_sdw: Add space for a terminator into DAIs array  \n  \nThe code uses the initialised member of the asoc_sdw_dailink struct to  \ndetermine if a member of the array is in use. However in the case the  \narray is completely full this will lead to an access 1 past the end of  \nthe array, expand the array by one entry to include a space for a  \nterminator. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-11T17:26:34.000000Z"}]}