{"vulnerability": "CVE-2024-4502", "sightings": [{"uuid": "80fee1e1-a2c5-4917-8857-d17daf278c28", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45023", "type": "seen", "source": "https://t.me/cvedetector/5370", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45023 - Linux Kernel Md Raid Data Corruption Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-45023 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmd/raid1: Fix data corruption for degraded array with slow disk  \n  \nread_balance() will avoid reading from slow disks as much as possible,  \nhowever, if valid data only lands in slow disks, and a new normal disk  \nis still in recovery, unrecovered data can be read:  \n  \nraid1_read_request  \n read_balance  \n  raid1_should_read_first  \n  -> return false  \n  choose_best_rdev  \n  -> normal disk is not recovered, return -1  \n  choose_bb_rdev  \n  -> missing the checking of recovery, return the normal disk  \n -> read unrecovered data  \n  \nRoot cause is that the checking of recovery is missing in  \nchoose_bb_rdev(). Hence add such checking to fix the problem.  \n  \nAlso fix similar problem in choose_slow_rdev(). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:22.000000Z"}, {"uuid": "bcd79d56-d688-4068-ad3b-d95d54de4df7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45020", "type": "seen", "source": "https://t.me/cvedetector/5369", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45020 - Linux Kernel BPF Kernel Verifier Out-of-Bounds Read\", \n  \"Content\": \"CVE ID : CVE-2024-45020 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Fix a kernel verifier crash in stacksafe()  \n  \nDaniel Hodges reported a kernel verifier crash when playing with sched-ext.  \nFurther investigation shows that the crash is due to invalid memory access  \nin stacksafe(). More specifically, it is the following code:  \n  \n    if (exact != NOT_EXACT &&  \n        old->stack[spi].slot_type[i % BPF_REG_SIZE] !=  \n        cur->stack[spi].slot_type[i % BPF_REG_SIZE])  \n            return false;  \n  \nThe 'i' iterates old->allocated_stack.  \nIf cur->allocated_stack allocated_stack the out-of-bound  \naccess will happen.  \n  \nTo fix the issue add 'i >= cur->allocated_stack' check such that if  \nthe condition is true, stacksafe() should fail. Otherwise,  \ncur->stack[spi].slot_type[i % BPF_REG_SIZE] memory access is legal. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:21.000000Z"}, {"uuid": "145dd203-651c-4946-9875-1eff645e3ab1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45025", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/5368", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45025 - Linux Kernel bitmap corruption vulnerability in close_range().\", \n  \"Content\": \"CVE ID : CVE-2024-45025 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE  \n  \ncopy_fd_bitmaps(new, old, count) is expected to copy the first  \ncount/BITS_PER_LONG bits from old->full_fds_bits[] and fill  \nthe rest with zeroes.  What it does is copying enough words  \n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.  \nThat works fine, *if* all bits past the cutoff point are  \nclear.  Otherwise we are risking garbage from the last word  \nwe'd copied.  \n  \nFor most of the callers that is true - expand_fdtable() has  \ncount equal to old->max_fds, so there's no open descriptors  \npast count, let alone fully occupied words in ->open_fds[],  \nwhich is what bits in ->full_fds_bits[] correspond to.  \n  \nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),  \nwhich is the smallest multiple of BITS_PER_LONG that covers all  \nopened descriptors below max_fds.  In the common case (copying on  \nfork()) max_fds is ~0U, so all opened descriptors will be below  \nit and we are fine, by the same reasons why the call in expand_fdtable()  \nis safe.  \n  \nUnfortunately, there is a case where max_fds is less than that  \nand where we might, indeed, end up with junk in ->full_fds_bits[] -  \nclose_range(from, to, CLOSE_RANGE_UNSHARE) with  \n * descriptor table being currently shared  \n * 'to' being above the current capacity of descriptor table  \n * 'from' being just under some chunk of opened descriptors.  \nIn that case we end up with observably wrong behaviour - e.g. spawn  \na child with CLONE_FILES, get all descriptors in range 0..127 open,  \nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending  \nup with descriptor #128, despite #64 being observably not open.  \n  \nThe minimally invasive fix would be to deal with that in dup_fd().  \nIf this proves to add measurable overhead, we can go that way, but  \nlet's try to fix copy_fd_bitmaps() first.  \n  \n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).  \n* make copy_fd_bitmaps() take the bitmap size in words, rather than  \nbits; it's 'count' argument is always a multiple of BITS_PER_LONG,  \nso we are not losing any information, and that way we can use the  \nsame helper for all three bitmaps - compiler will see that count  \nis a multiple of BITS_PER_LONG for the large ones, so it'll generate  \nplain memcpy()+memset().  \n  \nReproducer added to tools/testing/selftests/core/close_range_test.c \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:20.000000Z"}, {"uuid": "4098cf6c-5715-4797-9c5d-61d7af026bfa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45021", "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": "c219e6d3-ce63-44b1-bd03-19d1c36f9500", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45025", "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": "b623acd8-2ced-450a-a1a6-9c141fdb7bcb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45027", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/15706", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-45027\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()\n\nIf xhci_mem_init() fails, it calls into xhci_mem_cleanup() to mop\nup the damage. If it fails early enough, before xhci->interrupters\nis allocated but after xhci->max_interrupters has been set, which\nhappens in most (all?) cases, things get uglier, as xhci_mem_cleanup()\nunconditionally derefences xhci->interrupters. With prejudice.\n\nGate the interrupt freeing loop with a check on xhci->interrupters\nbeing non-NULL.\n\nFound while debugging a DMA allocation issue that led the XHCI driver\non this exact path.\n\ud83d\udccf Published: 2024-09-11T15:13:59.032Z\n\ud83d\udccf Modified: 2025-05-09T08:06:06.586Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/3efb29f6a78d4746f958c1ab6cd7981c5762f03b\n2. https://git.kernel.org/stable/c/770cacc75b0091ece17349195d72133912c1ca7c\n3. https://git.kernel.org/stable/c/dcdb52d948f3a17ccd3fce757d9bd981d7c32039", "creation_timestamp": "2025-05-09T08:25:26.000000Z"}, {"uuid": "47663c52-724f-4931-ace4-9955275b0786", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45021", "type": "seen", "source": "https://t.me/cvedetector/5380", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45021 - Linux Kernel User-Triggerable OOPs in Memcg Write Event Control\", \n  \"Content\": \"CVE ID : CVE-2024-45021 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmemcg_write_event_control(): fix a user-triggerable oops  \n  \nwe are *not* guaranteed that anything past the terminating NUL  \nis mapped (let alone initialized with anything sane). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:37.000000Z"}, {"uuid": "d479175f-8cbd-44cf-98d7-dce77477ebd5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45022", "type": "seen", "source": "https://t.me/cvedetector/5378", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45022 - Linux Kernel VMware Mapping Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-45022 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0  \n  \nThe __vmap_pages_range_noflush() assumes its argument pages** contains  \npages with the same page shift.  However, since commit e9c3cda4d86e (\"mm,  \nvmalloc: fix high order __GFP_NOFAIL allocations\"), if gfp_flags includes  \n__GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation  \nfailed for high order, the pages** may contain two different page shifts  \n(high order and order-0).  This could lead __vmap_pages_range_noflush() to  \nperform incorrect mappings, potentially resulting in memory corruption.  \n  \nUsers might encounter this as follows (vmap_allow_huge = true, 2M is for  \nPMD_SIZE):  \n  \nkvmalloc(2M, __GFP_NOFAIL|GFP_X)  \n    __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP)  \n        vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0  \n            vmap_pages_range()  \n                vmap_pages_range_noflush()  \n                    __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens  \n  \nWe can remove the fallback code because if a high-order allocation fails,  \n__vmalloc_node_range_noprof() will retry with order-0.  Therefore, it is  \nunnecessary to fallback to order-0 here.  Therefore, fix this by removing  \nthe fallback code. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:35.000000Z"}, {"uuid": "0e5b12c2-75fd-4cb9-8afe-141b57ac9b9d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45028", "type": "seen", "source": "https://t.me/cvedetector/5377", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45028 - Linux kernel MMC NULL Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-45028 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmmc: mmc_test: Fix NULL dereference on allocation failure  \n  \nIf the \"test->highmem = alloc_pages()\" allocation fails then calling  \n__free_pages(test->highmem) will result in a NULL dereference.  Also  \nchange the error code to -ENOMEM instead of returning success. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:34.000000Z"}, {"uuid": "5b7b3be0-1d6c-4da1-83d4-548703f2eaf3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45024", "type": "seen", "source": "https://t.me/cvedetector/5375", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45024 - Red Hat Linux Kernel HugeTLB Page Table Locking Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-45024 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/hugetlb: fix hugetlb vs. core-mm PT locking  \n  \nWe recently made GUP's common page table walking code to also walk hugetlb  \nVMAs without most hugetlb special-casing, preparing for the future of  \nhaving less hugetlb-specific page table walking code in the codebase.   \nTurns out that we missed one page table locking detail: page table locking  \nfor hugetlb folios that are not mapped using a single PMD/PUD.  \n  \nAssume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB  \nhugetlb folios on arm64 with 4 KiB base page size).  GUP, as it walks the  \npage tables, will perform a pte_offset_map_lock() to grab the PTE table  \nlock.  \n  \nHowever, hugetlb that concurrently modifies these page tables would  \nactually grab the mm->page_table_lock: with USE_SPLIT_PTE_PTLOCKS, the  \nlocks would differ.  Something similar can happen right now with hugetlb  \nfolios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS.  \n  \nThis issue can be reproduced [1], for example triggering:  \n  \n[ 3105.936100] ------------[ cut here ]------------  \n[ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188  \n[ 3105.944634] Modules linked in: [...]  \n[ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1  \n[ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024  \n[ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)  \n[ 3105.991108] pc : try_grab_folio+0x11c/0x188  \n[ 3105.994013] lr : follow_page_pte+0xd8/0x430  \n[ 3105.996986] sp : ffff80008eafb8f0  \n[ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43  \n[ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48  \n[ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978  \n[ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001  \n[ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000  \n[ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000  \n[ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0  \n[ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080  \n[ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000  \n[ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000  \n[ 3106.047957] Call trace:  \n[ 3106.049522]  try_grab_folio+0x11c/0x188  \n[ 3106.051996]  follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0  \n[ 3106.055527]  follow_page_mask+0x1a0/0x2b8  \n[ 3106.058118]  __get_user_pages+0xf0/0x348  \n[ 3106.060647]  faultin_page_range+0xb0/0x360  \n[ 3106.063651]  do_madvise+0x340/0x598  \n  \nLet's make huge_pte_lockptr() effectively use the same PT locks as any  \ncore-mm page table walker would.  Add ptep_lockptr() to obtain the PTE  \npage table lock using a pte pointer -- unfortunately we cannot convert  \npte_lockptr() because virt_to_page() doesn't work with kmap'ed page tables  \nwe can have with CONFIG_HIGHPTE.  \n  \nHandle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such  \nthat when e.g., CONFIG_PGTABLE_LEVELS==2 with  \nPGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected.  Document  \nwhy that works.  \n  \nThere is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb  \nfolio being mapped using two PTE page tables.  While hugetlb wants to take  \nthe PMD table lock, core-mm would grab the PTE table lock of one of both  \nPTE page tables.  In such corner cases, we have to make sure that both  \nlocks match, which is (fortunately!) currently guaranteed for 8xx as it  \ndoes not support SMP and consequently doesn't use split PT locks.  \n  \n[1]  \nSever[...]", "creation_timestamp": "2024-09-11T18:41:29.000000Z"}, {"uuid": "fbb769e2-f20f-4b67-9c88-b76f61cc9141", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45029", "type": "seen", "source": "https://t.me/cvedetector/5374", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45029 - Linux Tegra i2cacersenal/Irql Violation\", \n  \"Content\": \"CVE ID : CVE-2024-45029 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ni2c: tegra: Do not mark ACPI devices as irq safe  \n  \nOn ACPI machines, the tegra i2c module encounters an issue due to a  \nmutex being called inside a spinlock. This leads to the following bug:  \n  \n BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585  \n ...  \n  \n Call trace:  \n __might_sleep  \n __mutex_lock_common  \n mutex_lock_nested  \n acpi_subsys_runtime_resume  \n rpm_resume  \n tegra_i2c_xfer  \n  \nThe problem arises because during __pm_runtime_resume(), the spinlock  \n&dev->power.lock is acquired before rpm_resume() is called. Later,  \nrpm_resume() invokes acpi_subsys_runtime_resume(), which relies on  \nmutexes, triggering the error.  \n  \nTo address this issue, devices on ACPI are now marked as not IRQ-safe,  \nconsidering the dependency of acpi_subsys_runtime_resume() on mutexes. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:28.000000Z"}, {"uuid": "775fb207-03cb-42b7-b73e-a35e71dcd679", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45026", "type": "seen", "source": "https://t.me/cvedetector/5373", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45026 - IBM Dasd Thin Provisioned Volume Format Error Handling Vulnerability (Data Corruption)\", \n  \"Content\": \"CVE ID : CVE-2024-45026 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ns390/dasd: fix error recovery leading to data corruption on ESE devices  \n  \nExtent Space Efficient (ESE) or thin provisioned volumes need to be  \nformatted on demand during usual IO processing.  \n  \nThe dasd_ese_needs_format function checks for error codes that signal  \nthe non existence of a proper track format.  \n  \nThe check for incorrect length is to imprecise since other error cases  \nleading to transport of insufficient data also have this flag set.  \nThis might lead to data corruption in certain error cases for example  \nduring a storage server warmstart.  \n  \nFix by removing the check for incorrect length and replacing by  \nexplicitly checking for invalid track format in transport mode.  \n  \nAlso remove the check for file protected since this is not a valid  \nESE handling case. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:28.000000Z"}, {"uuid": "dfbf1c1c-d29e-45eb-9411-cd8bf925ad82", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-45027", "type": "seen", "source": "https://t.me/cvedetector/5379", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45027 - \"Huawei XHCI Uninitialized Pointer Derefence\"\", \n  \"Content\": \"CVE ID : CVE-2024-45027 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nusb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()  \n  \nIf xhci_mem_init() fails, it calls into xhci_mem_cleanup() to mop  \nup the damage. If it fails early enough, before xhci->interrupters  \nis allocated but after xhci->max_interrupters has been set, which  \nhappens in most (all?) cases, things get uglier, as xhci_mem_cleanup()  \nunconditionally derefences xhci->interrupters. With prejudice.  \n  \nGate the interrupt freeing loop with a check on xhci->interrupters  \nbeing non-NULL.  \n  \nFound while debugging a DMA allocation issue that led the XHCI driver  \non this exact path. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:36.000000Z"}]}