{"vulnerability": "cve-2024-5678", "sightings": [{"uuid": "5efe0729-2001-44a7-8cd0-ddcad57abe0c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56784", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lfatauzme62e", "content": "", "creation_timestamp": "2025-01-08T18:48:17.004578Z"}, {"uuid": "e6ac6b99-4e18-4b73-85e5-e0854003437d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56784", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/113794235285562743", "content": "", "creation_timestamp": "2025-01-08T18:50:33.138870Z"}, {"uuid": "5a5f6aca-af5e-4414-b4d5-82cbc719ca2c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56788", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfhs65qdod25", "content": "", "creation_timestamp": "2025-01-11T13:17:25.347836Z"}, {"uuid": "18d9a046-1a2d-4b6c-b88b-0d8f4f120ba4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56780", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfarhh3apq2i", "content": "", "creation_timestamp": "2025-01-08T18:16:05.253215Z"}, {"uuid": "b65731ef-259d-4b29-9567-1924a9f3c8be", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56781", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfarhj5n7w22", "content": "", "creation_timestamp": "2025-01-08T18:16:07.434542Z"}, {"uuid": "b1b78a73-92bb-4ccf-b934-e1718fc53e0d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56783", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfarhog3ei2i", "content": "", "creation_timestamp": "2025-01-08T18:16:13.127116Z"}, {"uuid": "7f86686f-c890-4bd0-95d1-01ff6b4c011f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56782", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfarhlucui2f", "content": "", "creation_timestamp": "2025-01-08T18:16:10.385035Z"}, {"uuid": "1047cc97-9c69-4119-a538-7f9e8be875b3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56784", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfarhqodjw2l", "content": "", "creation_timestamp": "2025-01-08T18:16:15.335262Z"}, {"uuid": "208e2b9c-7386-40dc-80b0-ca432c4e460e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56785", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfarhsw7ff2k", "content": "", "creation_timestamp": "2025-01-08T18:16:17.681648Z"}, {"uuid": "d80e4cea-a4b9-4c6a-8464-c3807fc5444c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56786", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfarhvrygf2f", "content": "", "creation_timestamp": "2025-01-08T18:16:20.680743Z"}, {"uuid": "6087949b-4e56-4abc-9f5c-e81f0b3e99e7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56787", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lfarhyf5tl2e", "content": "", "creation_timestamp": "2025-01-08T18:16:23.480832Z"}, {"uuid": "abcaa820-6c42-4298-91db-fe5033c35b72", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56780", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113794125498890301", "content": "", "creation_timestamp": "2025-01-08T18:22:38.182163Z"}, {"uuid": "08cefecd-ad89-447e-87b1-3f393522eb06", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56783", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lfatats7vq2q", "content": "", "creation_timestamp": "2025-01-08T18:48:12.244977Z"}, {"uuid": "04729956-f496-452f-88b3-38de54729840", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56782", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lfatau2g6r2b", "content": "", "creation_timestamp": "2025-01-08T18:48:13.474283Z"}, {"uuid": "9a4e4ac3-e92c-4683-b439-0649381b23b9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56781", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "b1e42d45-0555-42b9-a102-61857a2fa7b8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56780", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "dfd15bd7-eb32-40a4-b196-485c8b67e4ba", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56785", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "e5a886b7-6558-4e88-9662-49a3bdc1307d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-5678", "type": "seen", "source": "https://gist.github.com/cd1zz/aa95fc8e06911decc6ab4a72f4c26c2f", "content": "", "creation_timestamp": "2025-09-11T14:10:40.000000Z"}, {"uuid": "6e3d3483-5801-4975-80b4-c2dbed7fe42d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-5678", "type": "seen", "source": "https://gist.github.com/aurixai-solutions/313b026594574c70a22f8d72ef7c665b", "content": "", "creation_timestamp": "2026-02-21T06:48:02.000000Z"}, {"uuid": "c432e154-72ce-4174-8e55-20308442f3f9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-56782", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "f64e6c69-5774-45a1-97f2-8409278572ef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-56788", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "98d36ee2-7054-4300-8d9a-79305a045548", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-56787", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "c76e7059-3d5e-4499-9ffa-42c59c48ba9b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-56782", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "9143ed3b-662d-48b9-a39a-f4b63440ca12", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-56785", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "a10539b8-e368-49eb-81d3-078956a99db7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56785", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/767", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56785\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a\n\nFix the dtc warnings:\n\n    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider\n    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider\n    arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'\n\nAnd a runtime warning introduced in commit 045b14ca5c36 (\"of: WARN on\ndeprecated #address-cells/#size-cells handling\"):\n\n    WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0\n    Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0\n\nThe fix is similar to commit d89a415ff8d5 (\"MIPS: Loongson64: DTS: Fix PCIe\nport nodes for ls7a\"), which has fixed the issue for ls2k (despite its\nsubject mentions ls7a).\n\ud83d\udccf Published: 2025-01-08T17:52:01.312Z\n\ud83d\udccf Modified: 2025-01-08T17:52:01.312Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/5a2eaa3ad2b803c7ea442c6db7379466ee73c024\n2. https://git.kernel.org/stable/c/a7fd78075031871bc68fc56fdaa6e7a3934064b1\n3. https://git.kernel.org/stable/c/c8ee41fc3522c6659e324d90bc2ccd3b6310d7fc\n4. https://git.kernel.org/stable/c/8ef9ea1503d0a129cc6f5cf48fb63633efa5d766\n5. https://git.kernel.org/stable/c/01575f2ff8ba578a3436f230668bd056dc2eb823\n6. https://git.kernel.org/stable/c/4fbd66d8254cedfd1218393f39d83b6c07a01917", "creation_timestamp": "2025-01-08T18:19:41.000000Z"}, {"uuid": "92ff9428-ffc4-4991-abb5-085c9edaf521", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56784", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/768", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56784\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Adding array index check to prevent memory corruption\n\n[Why & How]\nArray indices out of bound caused memory corruption. Adding checks to\nensure that array index stays in bound.\n\ud83d\udccf Published: 2025-01-08T17:52:00.503Z\n\ud83d\udccf Modified: 2025-01-08T17:52:00.503Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/dff526dc3e27f5484f5ba11471b9fbbe681467f2\n2. https://git.kernel.org/stable/c/2c437d9a0b496168e1a1defd17b531f0a526dbe9", "creation_timestamp": "2025-01-08T18:19:56.000000Z"}, {"uuid": "0e3726f1-e438-4b97-8ec9-ec6f82871a56", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56781", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/771", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56781\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/prom_init: Fixup missing powermac #size-cells\n\nOn some powermacs `escc` nodes are missing `#size-cells` properties,\nwhich is deprecated and now triggers a warning at boot since commit\n045b14ca5c36 (\"of: WARN on deprecated #address-cells/#size-cells\nhandling\").\n\nFor example:\n\n  Missing '#size-cells' in /pci@f2000000/mac-io@c/escc@13000\n  WARNING: CPU: 0 PID: 0 at drivers/of/base.c:133 of_bus_n_size_cells+0x98/0x108\n  Hardware name: PowerMac3,1 7400 0xc0209 PowerMac\n  ...\n  Call Trace:\n    of_bus_n_size_cells+0x98/0x108 (unreliable)\n    of_bus_default_count_cells+0x40/0x60\n    __of_get_address+0xc8/0x21c\n    __of_address_to_resource+0x5c/0x228\n    pmz_init_port+0x5c/0x2ec\n    pmz_probe.isra.0+0x144/0x1e4\n    pmz_console_init+0x10/0x48\n    console_init+0xcc/0x138\n    start_kernel+0x5c4/0x694\n\nAs powermacs boot via prom_init it's possible to add the missing\nproperties to the device tree during boot, avoiding the warning. Note\nthat `escc-legacy` nodes are also missing `#size-cells` properties, but\nthey are skipped by the macio driver, so leave them alone.\n\nDepends-on: 045b14ca5c36 (\"of: WARN on deprecated #address-cells/#size-cells handling\")\n\ud83d\udccf Published: 2025-01-08T17:51:57.856Z\n\ud83d\udccf Modified: 2025-01-08T17:51:57.856Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/0b94d838018fb0a824e0cd3149034928c99fb1b7\n2. https://git.kernel.org/stable/c/a79a7e3c03ae2a07f68b5f24d5ed549f9799ec89\n3. https://git.kernel.org/stable/c/ee68554d2c03e32077f7b984e5289fdb005036d2\n4. https://git.kernel.org/stable/c/6d5f0453a2228607333bff0c85238a3cb495d194\n5. https://git.kernel.org/stable/c/691284c2cd33ffaa0b35ce53b3286b90621e9dc9\n6. https://git.kernel.org/stable/c/296a109fa77110ba5267fe0e90a26005eecc2726\n7. https://git.kernel.org/stable/c/cf89c9434af122f28a3552e6f9cc5158c33ce50a", "creation_timestamp": "2025-01-08T18:20:25.000000Z"}, {"uuid": "921fe5f5-17bd-4d70-b188-546ab0ca1e32", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56783", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/769", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56783\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level\n\ncgroup maximum depth is INT_MAX by default, there is a cgroup toggle to\nrestrict this maximum depth to a more reasonable value not to harm\nperformance. Remove unnecessary WARN_ON_ONCE which is reachable from\nuserspace.\n\ud83d\udccf Published: 2025-01-08T17:51:59.704Z\n\ud83d\udccf Modified: 2025-01-08T17:51:59.704Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/7064a6daa4a700a298fe3aee11dea296bfe59fc4\n2. https://git.kernel.org/stable/c/2f9bec0a749eb646b384fde0c7b7c24687b2ffae\n3. https://git.kernel.org/stable/c/e227c042580ab065edc610c9ddc9bea691e6fc4d\n4. https://git.kernel.org/stable/c/b7529880cb961d515642ce63f9d7570869bbbdc3", "creation_timestamp": "2025-01-08T18:20:14.000000Z"}, {"uuid": "71a815fe-5fa5-4d76-9017-b8c26f0be337", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56782", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/770", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56782\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: x86: Add adev NULL check to acpi_quirk_skip_serdev_enumeration()\n\nacpi_dev_hid_match() does not check for adev == NULL, dereferencing\nit unconditional.\n\nAdd a check for adev being NULL before calling acpi_dev_hid_match().\n\nAt the moment acpi_quirk_skip_serdev_enumeration() is never called with\na controller_parent without an ACPI companion, but better safe than sorry.\n\ud83d\udccf Published: 2025-01-08T17:51:58.768Z\n\ud83d\udccf Modified: 2025-01-08T17:51:58.768Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/e173bce05f7032a8b4964cfef82a4b7668f5f3af\n2. https://git.kernel.org/stable/c/4a49194f587a62d972b602e3e1a2c3cfe6567966", "creation_timestamp": "2025-01-08T18:20:19.000000Z"}, {"uuid": "e7027454-a5b5-4a48-88e3-373934c2805e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56780", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/773", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56780\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nquota: flush quota_release_work upon quota writeback\n\nOne of the paths quota writeback is called from is:\n\nfreeze_super()\n  sync_filesystem()\n    ext4_sync_fs()\n      dquot_writeback_dquots()\n\nSince we currently don't always flush the quota_release_work queue in\nthis path, we can end up with the following race:\n\n 1. dquot are added to releasing_dquots list during regular operations.\n 2. FS Freeze starts, however, this does not flush the quota_release_work queue.\n 3. Freeze completes.\n 4. Kernel eventually tries to flush the workqueue while FS is frozen which\n    hits a WARN_ON since transaction gets started during frozen state:\n\n  ext4_journal_check_start+0x28/0x110 [ext4] (unreliable)\n  __ext4_journal_start_sb+0x64/0x1c0 [ext4]\n  ext4_release_dquot+0x90/0x1d0 [ext4]\n  quota_release_workfn+0x43c/0x4d0\n\nWhich is the following line:\n\n  WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);\n\nWhich ultimately results in generic/390 failing due to dmesg\nnoise. This was detected on powerpc machine 15 cores.\n\nTo avoid this, make sure to flush the workqueue during\ndquot_writeback_dquots() so we dont have any pending workitems after\nfreeze.\n\ud83d\udccf Published: 2025-01-08T17:49:17.889Z\n\ud83d\udccf Modified: 2025-01-08T17:49:17.889Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/a5abba5e0e586e258ded3e798fe5f69c66fec198\n2. https://git.kernel.org/stable/c/6f3821acd7c3143145999248087de5fb4b48cf26\n3. https://git.kernel.org/stable/c/ab6cfcf8ed2c7496f55d020b65b1d8cd55d9a2cb\n4. https://git.kernel.org/stable/c/3e6ff207cd5bd924ad94cd1a7c633bcdac0ba1cb\n5. https://git.kernel.org/stable/c/bcacb52a985f1b6d280f698a470b873dfe52728a\n6. https://git.kernel.org/stable/c/8ea87e34792258825d290f4dc5216276e91cb224\n7. https://git.kernel.org/stable/c/ac6f420291b3fee1113f21d612fa88b628afab5b", "creation_timestamp": "2025-01-08T18:21:03.000000Z"}, {"uuid": "1bb2f2e3-35a0-4a46-89e4-c3ae4fbccb95", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56786", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/766", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56786\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: put bpf_link's program when link is safe to be deallocated\n\nIn general, BPF link's underlying BPF program should be considered to be\nreachable through attach hook -> link -> prog chain, and, pessimistically,\nwe have to assume that as long as link's memory is not safe to free,\nattach hook's code might hold a pointer to BPF program and use it.\n\nAs such, it's not (generally) correct to put link's program early before\nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we\ncurrently do is mostly correct due to BPF program's release code doing\nsimilar RCU GP waiting, but as will be shown in the following patches,\nBPF program can be non-sleepable (and, thus, reliant on only \"classic\"\nRCU GP), while BPF link's attach hook can have sleepable semantics and\nneeds to be protected by RCU Tasks Trace, and for such cases BPF link\nhas to go through RCU Tasks Trace + \"classic\" RCU GPs before being\ndeallocated. And so, if we put BPF program early, we might free BPF\nprogram before we free BPF link, leading to use-after-free situation.\n\nSo, this patch defers bpf_prog_put() until we are ready to perform\nbpf_link's deallocation. At worst, this delays BPF program freeing by\none extra RCU GP, but that seems completely acceptable. Alternatively,\nwe'd need more elaborate ways to determine BPF hook, BPF link, and BPF\nprogram lifetimes, and how they relate to each other, which seems like\nan unnecessary complication.\n\nNote, for most BPF links we still will perform eager bpf_prog_put() and\nlink dealloc, so for those BPF links there are no observable changes\nwhatsoever. Only BPF links that use deferred dealloc might notice\nslightly delayed freeing of BPF programs.\n\nAlso, to reduce code and logic duplication, extract program put + link\ndealloc logic into bpf_link_dealloc() helper.\n\ud83d\udccf Published: 2025-01-08T17:52:02.435Z\n\ud83d\udccf Modified: 2025-01-08T17:52:02.435Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b\n2. https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885\n3. https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f", "creation_timestamp": "2025-01-08T18:19:11.000000Z"}, {"uuid": "15bbcc7b-64ce-4e8f-9750-3205384ef91d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56787", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/765", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56787\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: imx8m: Probe the SoC driver as platform driver\n\nWith driver_async_probe=* on kernel command line, the following trace is\nproduced because on i.MX8M Plus hardware because the soc-imx8m.c driver\ncalls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock\ndriver is not yet probed. This was not detected during regular testing\nwithout driver_async_probe.\n\nConvert the SoC code to platform driver and instantiate a platform device\nin its current device_initcall() to probe the platform driver. Rework\n.soc_revision callback to always return valid error code and return SoC\nrevision via parameter. This way, if anything in the .soc_revision callback\nreturn -EPROBE_DEFER, it gets propagated to .probe and the .probe will get\nretried later.\n\n\"\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180\nCPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603\nHardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : imx8mm_soc_revision+0xdc/0x180\nlr : imx8mm_soc_revision+0xd0/0x180\nsp : ffff8000821fbcc0\nx29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120\nx26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311\nx23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb\nx20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff\nx17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8\nx14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801\nx11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c\nx8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3\nx5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb\nCall trace:\n imx8mm_soc_revision+0xdc/0x180\n imx8_soc_init+0xb0/0x1e0\n do_one_initcall+0x94/0x1a8\n kernel_init_freeable+0x240/0x2a8\n kernel_init+0x28/0x140\n ret_from_fork+0x10/0x20\n---[ end trace 0000000000000000 ]---\nSoC: i.MX8MP revision 1.1\n\"\n\ud83d\udccf Published: 2025-01-08T17:52:03.420Z\n\ud83d\udccf Modified: 2025-01-08T17:52:03.420Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/e497edb8f31ec2c2b6f4ce930e175aa2da8be334\n2. https://git.kernel.org/stable/c/ea2ff66feb5f9b183f9e2f9d06c21340bd88de12\n3. https://git.kernel.org/stable/c/2129f6faa5dfe8c6b87aad11720bf75edd77d3e4\n4. https://git.kernel.org/stable/c/997a3c04d7fa3d1d385c14691350d096fada648c\n5. https://git.kernel.org/stable/c/9cc832d37799dbea950c4c8a34721b02b8b5a8ff", "creation_timestamp": "2025-01-08T18:18:50.000000Z"}, {"uuid": "82a1cbf7-f4d1-4b65-99ec-d5ff5e2ed329", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56788", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/1303", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56788\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: oa_tc6: fix tx skb race condition between reference pointers\n\nThere are two skb pointers to manage tx skb's enqueued from n/w stack.\nwaiting_tx_skb pointer points to the tx skb which needs to be processed\nand ongoing_tx_skb pointer points to the tx skb which is being processed.\n\nSPI thread prepares the tx data chunks from the tx skb pointed by the\nongoing_tx_skb pointer. When the tx skb pointed by the ongoing_tx_skb is\nprocessed, the tx skb pointed by the waiting_tx_skb is assigned to\nongoing_tx_skb and the waiting_tx_skb pointer is assigned with NULL.\nWhenever there is a new tx skb from n/w stack, it will be assigned to\nwaiting_tx_skb pointer if it is NULL. Enqueuing and processing of a tx skb\nhandled in two different threads.\n\nConsider a scenario where the SPI thread processed an ongoing_tx_skb and\nit moves next tx skb from waiting_tx_skb pointer to ongoing_tx_skb pointer\nwithout doing any NULL check. At this time, if the waiting_tx_skb pointer\nis NULL then ongoing_tx_skb pointer is also assigned with NULL. After\nthat, if a new tx skb is assigned to waiting_tx_skb pointer by the n/w\nstack and there is a chance to overwrite the tx skb pointer with NULL in\nthe SPI thread. Finally one of the tx skb will be left as unhandled,\nresulting packet missing and memory leak.\n\n- Consider the below scenario where the TXC reported from the previous\ntransfer is 10 and ongoing_tx_skb holds an tx ethernet frame which can be\ntransported in 20 TXCs and waiting_tx_skb is still NULL.\n tx_credits = 10; /* 21 are filled in the previous transfer */\n ongoing_tx_skb = 20;\n waiting_tx_skb = NULL; /* Still NULL */\n- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true.\n- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\n ongoing_tx_skb = 10;\n waiting_tx_skb = NULL; /* Still NULL */\n- Perform SPI transfer.\n- Process SPI rx buffer to get the TXC from footers.\n- Now let's assume previously filled 21 TXCs are freed so we are good to\ntransport the next remaining 10 tx chunks from ongoing_tx_skb.\n tx_credits = 21;\n ongoing_tx_skb = 10;\n waiting_tx_skb = NULL;\n- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true again.\n- In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\n ongoing_tx_skb = NULL;\n waiting_tx_skb = NULL;\n\n- Now the below bad case might happen,\n\nThread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler)\n--------------------------- -----------------------------------\n- if waiting_tx_skb is NULL\n    - if ongoing_tx_skb is NULL\n    - ongoing_tx_skb = waiting_tx_skb\n- waiting_tx_skb = skb\n    - waiting_tx_skb = NULL\n    ...\n    - ongoing_tx_skb = NULL\n- if waiting_tx_skb is NULL\n- waiting_tx_skb = skb\n\nTo overcome the above issue, protect the moving of tx skb reference from\nwaiting_tx_skb pointer to ongoing_tx_skb pointer and assigning new tx skb\nto waiting_tx_skb pointer, so that the other thread can't access the\nwaiting_tx_skb pointer until the current thread completes moving the tx\nskb reference safely.\n\ud83d\udccf Published: 2025-01-11T12:35:47.985Z\n\ud83d\udccf Modified: 2025-01-11T12:35:47.985Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775\n2. https://git.kernel.org/stable/c/e592b5110b3e9393881b0a019d86832bbf71a47f", "creation_timestamp": "2025-01-11T13:06:12.000000Z"}, {"uuid": "2bf648c5-2c43-4e63-b96e-40efb074efd9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-5678", "type": "seen", "source": "https://gist.github.com/harche/ac8e8399a9bf69091a38a5cf6e3bc56b", "content": "", "creation_timestamp": "2026-04-28T22:02:22.000000Z"}, {"uuid": "42b98e81-83db-44aa-87e6-1268fe0c71f2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56786", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/16640", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-56786\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: put bpf_link's program when link is safe to be deallocated\n\nIn general, BPF link's underlying BPF program should be considered to be\nreachable through attach hook -> link -> prog chain, and, pessimistically,\nwe have to assume that as long as link's memory is not safe to free,\nattach hook's code might hold a pointer to BPF program and use it.\n\nAs such, it's not (generally) correct to put link's program early before\nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we\ncurrently do is mostly correct due to BPF program's release code doing\nsimilar RCU GP waiting, but as will be shown in the following patches,\nBPF program can be non-sleepable (and, thus, reliant on only \"classic\"\nRCU GP), while BPF link's attach hook can have sleepable semantics and\nneeds to be protected by RCU Tasks Trace, and for such cases BPF link\nhas to go through RCU Tasks Trace + \"classic\" RCU GPs before being\ndeallocated. And so, if we put BPF program early, we might free BPF\nprogram before we free BPF link, leading to use-after-free situation.\n\nSo, this patch defers bpf_prog_put() until we are ready to perform\nbpf_link's deallocation. At worst, this delays BPF program freeing by\none extra RCU GP, but that seems completely acceptable. Alternatively,\nwe'd need more elaborate ways to determine BPF hook, BPF link, and BPF\nprogram lifetimes, and how they relate to each other, which seems like\nan unnecessary complication.\n\nNote, for most BPF links we still will perform eager bpf_prog_put() and\nlink dealloc, so for those BPF links there are no observable changes\nwhatsoever. Only BPF links that use deferred dealloc might notice\nslightly delayed freeing of BPF programs.\n\nAlso, to reduce code and logic duplication, extract program put + link\ndealloc logic into bpf_link_dealloc() helper.\n\ud83d\udccf Published: 2025-01-08T17:52:02.435Z\n\ud83d\udccf Modified: 2025-05-16T07:25:18.083Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b\n2. https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885\n3. https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f", "creation_timestamp": "2025-05-16T07:33:48.000000Z"}, {"uuid": "675b3bfa-0f6f-4423-8ed7-264ca3e442a5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56788", "type": "seen", "source": "https://t.me/cvedetector/15063", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56788 - \"Linux Ethernet oa tc6 Tx Skb Reference Pointer Race Condition Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-56788 \nPublished : Jan. 11, 2025, 1:15 p.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: ethernet: oa_tc6: fix tx skb race condition between reference pointers  \n  \nThere are two skb pointers to manage tx skb's enqueued from n/w stack.  \nwaiting_tx_skb pointer points to the tx skb which needs to be processed  \nand ongoing_tx_skb pointer points to the tx skb which is being processed.  \n  \nSPI thread prepares the tx data chunks from the tx skb pointed by the  \nongoing_tx_skb pointer. When the tx skb pointed by the ongoing_tx_skb is  \nprocessed, the tx skb pointed by the waiting_tx_skb is assigned to  \nongoing_tx_skb and the waiting_tx_skb pointer is assigned with NULL.  \nWhenever there is a new tx skb from n/w stack, it will be assigned to  \nwaiting_tx_skb pointer if it is NULL. Enqueuing and processing of a tx skb  \nhandled in two different threads.  \n  \nConsider a scenario where the SPI thread processed an ongoing_tx_skb and  \nit moves next tx skb from waiting_tx_skb pointer to ongoing_tx_skb pointer  \nwithout doing any NULL check. At this time, if the waiting_tx_skb pointer  \nis NULL then ongoing_tx_skb pointer is also assigned with NULL. After  \nthat, if a new tx skb is assigned to waiting_tx_skb pointer by the n/w  \nstack and there is a chance to overwrite the tx skb pointer with NULL in  \nthe SPI thread. Finally one of the tx skb will be left as unhandled,  \nresulting packet missing and memory leak.  \n  \n- Consider the below scenario where the TXC reported from the previous  \ntransfer is 10 and ongoing_tx_skb holds an tx ethernet frame which can be  \ntransported in 20 TXCs and waiting_tx_skb is still NULL.  \n tx_credits = 10; /* 21 are filled in the previous transfer */  \n ongoing_tx_skb = 20;  \n waiting_tx_skb = NULL; /* Still NULL */  \n- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true.  \n- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs()  \n ongoing_tx_skb = 10;  \n waiting_tx_skb = NULL; /* Still NULL */  \n- Perform SPI transfer.  \n- Process SPI rx buffer to get the TXC from footers.  \n- Now let's assume previously filled 21 TXCs are freed so we are good to  \ntransport the next remaining 10 tx chunks from ongoing_tx_skb.  \n tx_credits = 21;  \n ongoing_tx_skb = 10;  \n waiting_tx_skb = NULL;  \n- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true again.  \n- In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs()  \n ongoing_tx_skb = NULL;  \n waiting_tx_skb = NULL;  \n  \n- Now the below bad case might happen,  \n  \nThread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler)  \n--------------------------- -----------------------------------  \n- if waiting_tx_skb is NULL  \n    - if ongoing_tx_skb is NULL  \n    - ongoing_tx_skb = waiting_tx_skb  \n- waiting_tx_skb = skb  \n    - waiting_tx_skb = NULL  \n    ...  \n    - ongoing_tx_skb = NULL  \n- if waiting_tx_skb is NULL  \n- waiting_tx_skb = skb  \n  \nTo overcome the above issue, protect the moving of tx skb reference from  \nwaiting_tx_skb pointer to ongoing_tx_skb pointer and assigning new tx skb  \nto waiting_tx_skb pointer, so that the other thread can't access the  \nwaiting_tx_skb pointer until the current thread completes moving the tx  \nskb reference safely. \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-11T14:55:15.000000Z"}, {"uuid": "6aac5d60-1506-4895-aa4a-2f25cceeacdb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56784", "type": "seen", "source": "https://t.me/cvedetector/14707", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56784 - AMD Display Array Index Out-of-Bound Write Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-56784 \nPublished : Jan. 8, 2025, 6:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amd/display: Adding array index check to prevent memory corruption  \n  \n[Why & How]  \nArray indices out of bound caused memory corruption. Adding checks to  \nensure that array index stays in bound. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-08T19:59:49.000000Z"}, {"uuid": "d0fade13-691c-4e04-ab15-51c046ec7286", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56783", "type": "seen", "source": "https://t.me/cvedetector/14706", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56783 - Linux Kernel Netfilter Cgroup Depth Denial of Service\", \n  \"Content\": \"CVE ID : CVE-2024-56783 \nPublished : Jan. 8, 2025, 6:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level  \n  \ncgroup maximum depth is INT_MAX by default, there is a cgroup toggle to  \nrestrict this maximum depth to a more reasonable value not to harm  \nperformance. Remove unnecessary WARN_ON_ONCE which is reachable from  \nuserspace. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-08T19:59:45.000000Z"}, {"uuid": "c8d6b290-fd3b-482b-a3e0-01b02f5ae98d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56782", "type": "seen", "source": "https://t.me/cvedetector/14705", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56782 - \"ACPI x86 NULL Pointer Dereference Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-56782 \nPublished : Jan. 8, 2025, 6:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nACPI: x86: Add adev NULL check to acpi_quirk_skip_serdev_enumeration()  \n  \nacpi_dev_hid_match() does not check for adev == NULL, dereferencing  \nit unconditional.  \n  \nAdd a check for adev being NULL before calling acpi_dev_hid_match().  \n  \nAt the moment acpi_quirk_skip_serdev_enumeration() is never called with  \na controller_parent without an ACPI companion, but better safe than sorry. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-08T19:59:44.000000Z"}, {"uuid": "8389c544-3e73-4b71-bea3-defed3dcccdd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56781", "type": "seen", "source": "https://t.me/cvedetector/14704", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56781 - \"Powermac PowerPC #size-cells Property Missing Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-56781 \nPublished : Jan. 8, 2025, 6:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npowerpc/prom_init: Fixup missing powermac #size-cells  \n  \nOn some powermacs `escc` nodes are missing `#size-cells` properties,  \nwhich is deprecated and now triggers a warning at boot since commit  \n045b14ca5c36 (\"of: WARN on deprecated #address-cells/#size-cells  \nhandling\").  \n  \nFor example:  \n  \n  Missing '#size-cells' in /pci@f2000000/mac-io@c/escc@13000  \n  WARNING: CPU: 0 PID: 0 at drivers/of/base.c:133 of_bus_n_size_cells+0x98/0x108  \n  Hardware name: PowerMac3,1 7400 0xc0209 PowerMac  \n  ...  \n  Call Trace:  \n    of_bus_n_size_cells+0x98/0x108 (unreliable)  \n    of_bus_default_count_cells+0x40/0x60  \n    __of_get_address+0xc8/0x21c  \n    __of_address_to_resource+0x5c/0x228  \n    pmz_init_port+0x5c/0x2ec  \n    pmz_probe.isra.0+0x144/0x1e4  \n    pmz_console_init+0x10/0x48  \n    console_init+0xcc/0x138  \n    start_kernel+0x5c4/0x694  \n  \nAs powermacs boot via prom_init it's possible to add the missing  \nproperties to the device tree during boot, avoiding the warning. Note  \nthat `escc-legacy` nodes are also missing `#size-cells` properties, but  \nthey are skipped by the macio driver, so leave them alone.  \n  \nDepends-on: 045b14ca5c36 (\"of: WARN on deprecated #address-cells/#size-cells handling\") \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-08T19:59:43.000000Z"}, {"uuid": "e2a2a683-a5ba-41cd-971c-ae75fd78426f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56780", "type": "seen", "source": "https://t.me/cvedetector/14717", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56780 - Linux quota kernel Freeze\u2122 DoS Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-56780 \nPublished : Jan. 8, 2025, 6:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nquota: flush quota_release_work upon quota writeback  \n  \nOne of the paths quota writeback is called from is:  \n  \nfreeze_super()  \n  sync_filesystem()  \n    ext4_sync_fs()  \n      dquot_writeback_dquots()  \n  \nSince we currently don't always flush the quota_release_work queue in  \nthis path, we can end up with the following race:  \n  \n 1. dquot are added to releasing_dquots list during regular operations.  \n 2. FS Freeze starts, however, this does not flush the quota_release_work queue.  \n 3. Freeze completes.  \n 4. Kernel eventually tries to flush the workqueue while FS is frozen which  \n    hits a WARN_ON since transaction gets started during frozen state:  \n  \n  ext4_journal_check_start+0x28/0x110 [ext4] (unreliable)  \n  __ext4_journal_start_sb+0x64/0x1c0 [ext4]  \n  ext4_release_dquot+0x90/0x1d0 [ext4]  \n  quota_release_workfn+0x43c/0x4d0  \n  \nWhich is the following line:  \n  \n  WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);  \n  \nWhich ultimately results in generic/390 failing due to dmesg  \nnoise. This was detected on powerpc machine 15 cores.  \n  \nTo avoid this, make sure to flush the workqueue during  \ndquot_writeback_dquots() so we dont have any pending workitems after  \nfreeze. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-08T20:00:03.000000Z"}, {"uuid": "14bef3e9-9fb4-4505-bad7-1dc7cc41f6e5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56787", "type": "seen", "source": "https://t.me/cvedetector/14710", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56787 - IBM i.MX8M Platform Driver PCIe Pseudo-Retrieval Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-56787 \nPublished : Jan. 8, 2025, 6:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsoc: imx8m: Probe the SoC driver as platform driver  \n  \nWith driver_async_probe=* on kernel command line, the following trace is  \nproduced because on i.MX8M Plus hardware because the soc-imx8m.c driver  \ncalls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock  \ndriver is not yet probed. This was not detected during regular testing  \nwithout driver_async_probe.  \n  \nConvert the SoC code to platform driver and instantiate a platform device  \nin its current device_initcall() to probe the platform driver. Rework  \n.soc_revision callback to always return valid error code and return SoC  \nrevision via parameter. This way, if anything in the .soc_revision callback  \nreturn -EPROBE_DEFER, it gets propagated to .probe and the .probe will get  \nretried later.  \n  \n\"  \n------------[ cut here ]------------  \nWARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180  \nCPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603  \nHardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)  \npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)  \npc : imx8mm_soc_revision+0xdc/0x180  \nlr : imx8mm_soc_revision+0xd0/0x180  \nsp : ffff8000821fbcc0  \nx29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120  \nx26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311  \nx23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb  \nx20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff  \nx17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8  \nx14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801  \nx11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c  \nx8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3  \nx5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000  \nx2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb  \nCall trace:  \n imx8mm_soc_revision+0xdc/0x180  \n imx8_soc_init+0xb0/0x1e0  \n do_one_initcall+0x94/0x1a8  \n kernel_init_freeable+0x240/0x2a8  \n kernel_init+0x28/0x140  \n ret_from_fork+0x10/0x20  \n---[ end trace 0000000000000000 ]---  \nSoC: i.MX8MP revision 1.1  \n\" \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-08T19:59:51.000000Z"}, {"uuid": "dea923b3-593f-4d0c-a37d-9c4cc98138bf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56786", "type": "seen", "source": "https://t.me/cvedetector/14709", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56786 - Linux kernel a BPF Link Use-After-Free Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-56786 \nPublished : Jan. 8, 2025, 6:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: put bpf_link's program when link is safe to be deallocated  \n  \nIn general, BPF link's underlying BPF program should be considered to be  \nreachable through attach hook -> link -> prog chain, and, pessimistically,  \nwe have to assume that as long as link's memory is not safe to free,  \nattach hook's code might hold a pointer to BPF program and use it.  \n  \nAs such, it's not (generally) correct to put link's program early before  \nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we  \ncurrently do is mostly correct due to BPF program's release code doing  \nsimilar RCU GP waiting, but as will be shown in the following patches,  \nBPF program can be non-sleepable (and, thus, reliant on only \"classic\"  \nRCU GP), while BPF link's attach hook can have sleepable semantics and  \nneeds to be protected by RCU Tasks Trace, and for such cases BPF link  \nhas to go through RCU Tasks Trace + \"classic\" RCU GPs before being  \ndeallocated. And so, if we put BPF program early, we might free BPF  \nprogram before we free BPF link, leading to use-after-free situation.  \n  \nSo, this patch defers bpf_prog_put() until we are ready to perform  \nbpf_link's deallocation. At worst, this delays BPF program freeing by  \none extra RCU GP, but that seems completely acceptable. Alternatively,  \nwe'd need more elaborate ways to determine BPF hook, BPF link, and BPF  \nprogram lifetimes, and how they relate to each other, which seems like  \nan unnecessary complication.  \n  \nNote, for most BPF links we still will perform eager bpf_prog_put() and  \nlink dealloc, so for those BPF links there are no observable changes  \nwhatsoever. Only BPF links that use deferred dealloc might notice  \nslightly delayed freeing of BPF programs.  \n  \nAlso, to reduce code and logic duplication, extract program put + link  \ndealloc logic into bpf_link_dealloc() helper. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-08T19:59:50.000000Z"}, {"uuid": "8c3e7cd6-8b9b-42cf-b1cc-0da50dbf2eee", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56785", "type": "seen", "source": "https://t.me/cvedetector/14708", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56785 - \"Loongson64 DTS PCIe Port Node Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-56785 \nPublished : Jan. 8, 2025, 6:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nMIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a  \n  \nFix the dtc warnings:  \n  \n    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider  \n    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider  \n    arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'  \n  \nAnd a runtime warning introduced in commit 045b14ca5c36 (\"of: WARN on  \ndeprecated #address-cells/#size-cells handling\"):  \n  \n    WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0  \n    Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0  \n  \nThe fix is similar to commit d89a415ff8d5 (\"MIPS: Loongson64: DTS: Fix PCIe  \nport nodes for ls7a\"), which has fixed the issue for ls2k (despite its  \nsubject mentions ls7a). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-08T19:59:50.000000Z"}, {"uuid": "7145c7c6-34a8-4df8-a86b-4f5234c58cd8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-5678", "type": "seen", "source": "https://t.me/cvedetector/2220", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-5678 - Zohocorp ManageEngine Applications Manager SQL Injection\", \n  \"Content\": \"CVE ID : CVE-2024-5678 \nPublished : Aug. 1, 2024, 7:15 a.m. | 40\u00a0minutes ago \nDescription : Zohocorp ManageEngine Applications Manager versions\u00a0170900 and below are vulnerable to the authenticated admin-only SQL Injection in the Create Monitor feature. \nSeverity: 4.7 | MEDIUM \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"01 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-01T10:24:25.000000Z"}]}