{"vulnerability": "cve-2024-4500", "sightings": [{"uuid": "77ff12e0-8d80-45a3-bc57-6c6504eed576", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45003", "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": "f40012a2-b7fd-4214-9a07-0ccb604e5580", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45006", "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": "5787a87f-8bc9-4cdb-8042-9c62f482b37b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45008", "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": "ce7dc813-1f3a-4bca-83dc-c65f1cde506e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45005", "type": "seen", "source": "https://t.me/cvedetector/4861", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45005 - IBM S390 KVM SIE Validity Interception Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-45005 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nKVM: s390: fix validity interception issue when gisa is switched off  \n  \nWe might run into a SIE validity if gisa has been disabled either via using  \nkernel parameter \"kvm.use_gisa=0\" or by setting the related sysfs  \nattribute to N (echo N >/sys/module/kvm/parameters/use_gisa).  \n  \nThe validity is caused by an invalid value in the SIE control block's  \ngisa designation. That happens because we pass the uninitialized gisa  \norigin to virt_to_phys() before writing it to the gisa designation.  \n  \nTo fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0.  \nkvm_s390_get_gisa_desc() is used to determine which gisa designation to  \nset in the SIE control block. A value of 0 in the gisa designation disables  \ngisa usage.  \n  \nThe issue surfaces in the host kernel with the following kernel message as  \nsoon a new kvm guest start is attemted.  \n  \nkvm: unhandled validity intercept 0x1011  \nWARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]  \nModules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci]  \nCPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6  \nHardware name: IBM 3931 A01 701 (LPAR)  \nKrnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm])  \n           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3  \nKrnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000  \n           000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff  \n           000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412  \n           000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960  \nKrnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4  \n           000003d93deb0118: c0e53fa8beac brasl %r14,000003d9bd3c7e70  \n          #000003d93deb011e: af000000  mc 0,0  \n          >000003d93deb0122: a728ffea  lhi %r2,-22  \n           000003d93deb0126: a7f4fe24  brc 15,000003d93deafd6e  \n           000003d93deb012a: 9101f0b0  tm 176(%r15),1  \n           000003d93deb012e: a774fe48  brc 7,000003d93deafdbe  \n           000003d93deb0132: 40a0f0ae  sth %r10,174(%r15)  \nCall Trace:  \n [] kvm_handle_sie_intercept+0x432/0x4d0 [kvm]  \n([] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm])  \n [] vcpu_post_run+0x1d0/0x3b0 [kvm]  \n [] __vcpu_run+0xea/0x2d0 [kvm]  \n [] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm]  \n [] kvm_vcpu_ioctl+0x190/0x7c0 [kvm]  \n [] vfs_ioctl+0x2e/0x70  \n [] __s390x_sys_ioctl+0xc2/0xd0  \n [] __do_syscall+0x1f2/0x2e0  \n [] system_call+0x70/0x98  \nLast Breaking-Event-Address:  \n [] __warn_printk+0xe8/0xf0 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:47:29.000000Z"}, {"uuid": "11f0b301-c4db-4b3e-bd05-abdfb1a221f4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45007", "type": "seen", "source": "https://t.me/cvedetector/4853", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45007 - Xillybus Linux Workqueue Destruction Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-45007 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nchar: xillybus: Don't destroy workqueue from work item running on it  \n  \nTriggered by a kref decrement, destroy_workqueue() may be called from  \nwithin a work item for destroying its own workqueue. This illegal  \nsituation is averted by adding a module-global workqueue for exclusive  \nuse of the offending work item. Other work items continue to be queued  \non per-device workqueues to ensure performance. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:47:16.000000Z"}, {"uuid": "3b9dc2f8-82f4-4092-b844-602041a71e72", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45000", "type": "seen", "source": "https://t.me/cvedetector/4871", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45000 - HP ProLiant Linux Kernel Null Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-45000 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfs/netfs/fscache_cookie: add missing \"n_accesses\" check  \n  \nThis fixes a NULL pointer dereference bug due to a data race which  \nlooks like this:  \n  \n  BUG: kernel NULL pointer dereference, address: 0000000000000008  \n  #PF: supervisor read access in kernel mode  \n  #PF: error_code(0x0000) - not-present page  \n  PGD 0 P4D 0  \n  Oops: 0000 [#1] SMP PTI  \n  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43  \n  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018  \n  Workqueue: events_unbound netfs_rreq_write_to_cache_work  \n  RIP: 0010:cachefiles_prepare_write+0x30/0xa0  \n  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20  8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10  \n  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286  \n  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000  \n  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438  \n  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001  \n  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68  \n  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00  \n  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000  \n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0  \n  Call Trace:  \n     \n   ? __die+0x1f/0x70  \n   ? page_fault_oops+0x15d/0x440  \n   ? search_module_extables+0xe/0x40  \n   ? fixup_exception+0x22/0x2f0  \n   ? exc_page_fault+0x5f/0x100  \n   ? asm_exc_page_fault+0x22/0x30  \n   ? cachefiles_prepare_write+0x30/0xa0  \n   netfs_rreq_write_to_cache_work+0x135/0x2e0  \n   process_one_work+0x137/0x2c0  \n   worker_thread+0x2e9/0x400  \n   ? __pfx_worker_thread+0x10/0x10  \n   kthread+0xcc/0x100  \n   ? __pfx_kthread+0x10/0x10  \n   ret_from_fork+0x30/0x50  \n   ? __pfx_kthread+0x10/0x10  \n   ret_from_fork_asm+0x1b/0x30  \n     \n  Modules linked in:  \n  CR2: 0000000000000008  \n  ---[ end trace 0000000000000000 ]---  \n  \nThis happened because fscache_cookie_state_machine() was slow and was  \nstill running while another process invoked fscache_unuse_cookie();  \nthis led to a fscache_cookie_lru_do_one() call, setting the  \nFSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by  \nfscache_cookie_state_machine(), withdrawing the cookie via  \ncachefiles_withdraw_cookie(), clearing cookie->cache_priv.  \n  \nAt the same time, yet another process invoked  \ncachefiles_prepare_write(), which found a NULL pointer in this code  \nline:  \n  \n  struct cachefiles_object *object = cachefiles_cres_object(cres);  \n  \nThe next line crashes, obviously:  \n  \n  struct cachefiles_cache *cache = object->volume->cache;  \n  \nDuring cachefiles_prepare_write(), the \"n_accesses\" counter is  \nnon-zero (via fscache_begin_operation()).  The cookie must not be  \nwithdrawn until it drops to zero.  \n  \nThe counter is checked by fscache_cookie_state_machine() before  \nswitching to FSCACHE_COOKIE_STATE_RELINQUISHING and  \nFSCACHE_COOKIE_STATE_WITHDRAWING (in \"case  \nFSCACHE_COOKIE_STATE_FAILED\"), but not for  \nFSCACHE_COOKIE_STATE_LRU_DISCARDING (\"case  \nFSCACHE_COOKIE_STATE_ACTIVE\").  \n  \nThis patch adds the missing check.  With a non-zero access counter,  \nthe function returns and the next fscache_end_cookie_access() call  \nwill queue another fscache_cookie_state_machine() call to handle the  \nstill-pending FSCACHE_COOKIE_DO_LRU_DISCARD. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:48:16.000000Z"}, {"uuid": "56dc698e-85e9-40db-850b-1d3772c95679", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45001", "type": "seen", "source": "https://t.me/cvedetector/4869", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45001 - Linux MANA Driver Alignment Vulnerability (Integer Overflow)\", \n  \"Content\": \"CVE ID : CVE-2024-45001 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: mana: Fix RX buf alloc_size alignment and atomic op panic  \n  \nThe MANA driver's RX buffer alloc_size is passed into napi_build_skb() to  \ncreate SKB. skb_shinfo(skb) is located at the end of skb, and its alignment  \nis affected by the alloc_size passed into napi_build_skb(). The size needs  \nto be aligned properly for better performance and atomic operations.  \nOtherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic  \noperations may panic on the skb_shinfo(skb)->dataref due to alignment fault.  \n  \nTo fix this bug, add proper alignment to the alloc_size calculation.  \n  \nSample panic info:  \n[  253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce  \n[  253.300900] Mem abort info:  \n[  253.301760]   ESR = 0x0000000096000021  \n[  253.302825]   EC = 0x25: DABT (current EL), IL = 32 bits  \n[  253.304268]   SET = 0, FnV = 0  \n[  253.305172]   EA = 0, S1PTW = 0  \n[  253.306103]   FSC = 0x21: alignment fault  \nCall trace:  \n __skb_clone+0xfc/0x198  \n skb_clone+0x78/0xe0  \n raw6_local_deliver+0xfc/0x228  \n ip6_protocol_deliver_rcu+0x80/0x500  \n ip6_input_finish+0x48/0x80  \n ip6_input+0x48/0xc0  \n ip6_sublist_rcv_finish+0x50/0x78  \n ip6_sublist_rcv+0x1cc/0x2b8  \n ipv6_list_rcv+0x100/0x150  \n __netif_receive_skb_list_core+0x180/0x220  \n netif_receive_skb_list_internal+0x198/0x2a8  \n __napi_poll+0x138/0x250  \n net_rx_action+0x148/0x330  \n handle_softirqs+0x12c/0x3a0 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:47:40.000000Z"}, {"uuid": "617fd620-2492-47f0-bf37-0541359b931d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45002", "type": "seen", "source": "https://t.me/cvedetector/4867", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45002 - Linux Kernel rtla osnoise NULL Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-45002 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nrtla/osnoise: Prevent NULL dereference in error handling  \n  \nIf the \"tool->data\" allocation fails then there is no need to call  \nosnoise_free_top() and, in fact, doing so will lead to a NULL dereference. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:47:38.000000Z"}, {"uuid": "45361036-74a8-4385-acb0-8b7f16a10acb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45003", "type": "seen", "source": "https://t.me/cvedetector/4864", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45003 - Linux Kernel Ext4 and Ubifs INode LRU Isolation Deadlock\", \n  \"Content\": \"CVE ID : CVE-2024-45003 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nvfs: Don't evict inode under the inode lru traversing context  \n  \nThe inode reclaiming process(See function prune_icache_sb) collects all  \nreclaimable inodes and mark them with I_FREEING flag at first, at that  \ntime, other processes will be stuck if they try getting these inodes  \n(See function find_inode_fast), then the reclaiming process destroy the  \ninodes by function dispose_list(). Some filesystems(eg. ext4 with  \nea_inode feature, ubifs with xattr) may do inode lookup in the inode  \nevicting callback function, if the inode lookup is operated under the  \ninode lru traversing context, deadlock problems may happen.  \n  \nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen  \n        if ea_inode feature is enabled, the lookup process will be stuck  \n under the evicting context like this:  \n  \n 1. File A has inode i_reg and an ea inode i_ea  \n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea  \n 3. Then, following three processes running like this:  \n  \n    PA                              PB  \n echo 2 > /proc/sys/vm/drop_caches  \n  shrink_slab  \n   prune_dcache_sb  \n   // i_reg is added into lru, lru->i_ea->i_reg  \n   prune_icache_sb  \n    list_lru_walk_one  \n     inode_lru_isolate  \n      i_ea->i_state |= I_FREEING // set inode state  \n     inode_lru_isolate  \n      __iget(i_reg)  \n      spin_unlock(&i_reg->i_lock)  \n      spin_unlock(lru_lock)  \n                                     rm file A  \n                                      i_reg->nlink = 0  \n      iput(i_reg) // i_reg->nlink is 0, do evict  \n       ext4_evict_inode  \n        ext4_xattr_delete_inode  \n         ext4_xattr_inode_dec_ref_all  \n          ext4_xattr_inode_iget  \n           ext4_iget(i_ea->i_ino)  \n            iget_locked  \n             find_inode_fast  \n              __wait_on_freeing_inode(i_ea) ----\u2192 AA deadlock  \n    dispose_list // cannot be executed by prune_icache_sb  \n     wake_up_bit(&i_ea->i_state)  \n  \nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file  \n        deleting process holds BASEHD's wbuf->io_mutex while getting the  \n xattr inode, which could race with inode reclaiming process(The  \n        reclaiming process could try locking BASEHD's wbuf->io_mutex in  \n inode evicting function), then an ABBA deadlock problem would  \n happen as following:  \n  \n 1. File A has inode ia and a xattr(with inode ixa), regular file B has  \n    inode ib and a xattr.  \n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa  \n 3. Then, following three processes running like this:  \n  \n        PA                PB                        PC  \n                echo 2 > /proc/sys/vm/drop_caches  \n                 shrink_slab  \n                  prune_dcache_sb  \n                  // ib and ia are added into lru, lru->ixa->ib->ia  \n                  prune_icache_sb  \n                   list_lru_walk_one  \n                    inode_lru_isolate  \n                     ixa->i_state |= I_FREEING // set inode state  \n                    inode_lru_isolate  \n                     __iget(ib)  \n                     spin_unlock(&ib->i_lock)  \n                     spin_unlock(lru_lock)  \n                                                   rm file B  \n                                                    ib->nlink = 0  \n rm file A  \n  iput(ia)  \n   ubifs_evict_inode(ia)  \n    ubifs_jnl_delete_inode(ia)  \n     ubifs_jnl_write_inode(ia)  \n      make_reservation(BASEHD) // Lock wbuf->io_mutex  \n      ubifs_iget(ixa->i_ino)  \n       iget_locked  \n        find_inode_fast  \n         __wait_on_freeing_inode(ixa)  \n          |          iput(ib) // ib->nlink is 0, do evict  \n          |           ubifs_evict_inode  \n          |            ubifs_jnl_delete_inode(ib)  \n          \u2193  [...]", "creation_timestamp": "2024-09-04T22:47:32.000000Z"}, {"uuid": "464747fb-1a68-4697-8d17-3a4baecc3ffa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45004", "type": "seen", "source": "https://t.me/cvedetector/4863", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45004 - Apache Linux Key Encryption Key Leak\", \n  \"Content\": \"CVE ID : CVE-2024-45004 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nKEYS: trusted: dcp: fix leak of blob encryption key  \n  \nTrusted keys unseal the key blob on load, but keep the sealed payload in  \nthe blob field so that every subsequent read (export) will simply  \nconvert this field to hex and send it to userspace.  \n  \nWith DCP-based trusted keys, we decrypt the blob encryption key (BEK)  \nin the Kernel due hardware limitations and then decrypt the blob payload.  \nBEK decryption is done in-place which means that the trusted key blob  \nfield is modified and it consequently holds the BEK in plain text.  \nEvery subsequent read of that key thus send the plain text BEK instead  \nof the encrypted BEK to userspace.  \n  \nThis issue only occurs when importing a trusted DCP-based key and  \nthen exporting it again. This should rarely happen as the common use cases  \nare to either create a new trusted key and export it, or import a key  \nblob and then just use it without exporting it again.  \n  \nFix this by performing BEK decryption and encryption in a dedicated  \nbuffer. Further always wipe the plain text BEK buffer to prevent leaking  \nthe key via uninitialized memory. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:47:31.000000Z"}, {"uuid": "db879f7c-094b-490e-8016-69f0438aab83", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45006", "type": "seen", "source": "https://t.me/cvedetector/4859", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45006 - Here is a possible title for the vulnerability: \"Gigabyte xHCI NULL Pointer Dereference Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-45006 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nxhci: Fix Panther point NULL pointer deref at full-speed re-enumeration  \n  \nre-enumerating full-speed devices after a failed address device command  \ncan trigger a NULL pointer dereference.  \n  \nFull-speed devices may need to reconfigure the endpoint 0 Max Packet Size  \nvalue during enumeration. Usb core calls usb_ep0_reinit() in this case,  \nwhich ends up calling xhci_configure_endpoint().  \n  \nOn Panther point xHC the xhci_configure_endpoint() function will  \nadditionally check and reserve bandwidth in software. Other hosts do  \nthis in hardware  \n  \nIf xHC address device command fails then a new xhci_virt_device structure  \nis allocated as part of re-enabling the slot, but the bandwidth table  \npointers are not set up properly here.  \nThis triggers the NULL pointer dereference the next time usb_ep0_reinit()  \nis called and xhci_configure_endpoint() tries to check and reserve  \nbandwidth  \n  \n[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd  \n[46710.713699] usb 3-1: Device not responding to setup address.  \n[46710.917684] usb 3-1: Device not responding to setup address.  \n[46711.125536] usb 3-1: device not accepting address 5, error -71  \n[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008  \n[46711.125600] #PF: supervisor read access in kernel mode  \n[46711.125603] #PF: error_code(0x0000) - not-present page  \n[46711.125606] PGD 0 P4D 0  \n[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI  \n[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1  \n[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.  \n[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]  \n[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c  \n  \nFix this by making sure bandwidth table pointers are set up correctly  \nafter a failed address device command, and additionally by avoiding  \nchecking for bandwidth in cases like this where no actual endpoints are  \nadded or removed, i.e. only context for default control endpoint 0 is  \nevaluated. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:47:25.000000Z"}, {"uuid": "cf7dac41-7d9d-49e0-9e65-7fd021ab4b9f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45008", "type": "seen", "source": "https://t.me/cvedetector/4851", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45008 - Linux kernel Denial of Service\", \n  \"Content\": \"CVE ID : CVE-2024-45008 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nInput: MT - limit max slots  \n  \nsyzbot is reporting too large allocation at input_mt_init_slots(), for  \nnum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).  \n  \nSince nobody knows possible max slots, this patch chose 1024. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:47:15.000000Z"}]}