{"vulnerability": "CVE-2023-5289", "sightings": [{"uuid": "3a8d6071-2a77-40c2-9448-f5b8f22aae5b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-5289", "type": "seen", "source": "https://t.me/cibsecurity/71299", "content": "\u203c CVE-2023-5289 \u203c\n\nAllocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.8.4.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2023-09-29T18:37:49.000000Z"}, {"uuid": "830ffe35-7646-48c8-bdce-d6d34b838302", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-52896", "type": "seen", "source": "https://t.me/cvedetector/3758", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2023-52896 - \"Btrfs Quota Rescan Null Pointer Dereference\"\", \n  \"Content\": \"CVE ID : CVE-2023-52896 \nPublished : Aug. 21, 2024, 7:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbtrfs: fix race between quota rescan and disable leading to NULL pointer deref  \n  \nIf we have one task trying to start the quota rescan worker while another  \none is trying to disable quotas, we can end up hitting a race that results  \nin the quota rescan worker doing a NULL pointer dereference. The steps for  \nthis are the following:  \n  \n1) Quotas are enabled;  \n  \n2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().  \n   It calls qgroup_rescan_init() which returns 0 (success) and then joins a  \n   transaction and commits it;  \n  \n3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().  \n   It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info->flags and calls  \n   btrfs_qgroup_wait_for_completion(), which returns immediately since the  \n   rescan worker is not yet running.  \n   Then it starts a transaction and locks fs_info->qgroup_ioctl_lock;  \n  \n4) Task A queues the rescan worker, by calling btrfs_queue_work();  \n  \n5) The rescan worker starts, and calls rescan_should_stop() at the start  \n   of its while loop, which results in 0 iterations of the loop, since  \n   the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info->flags by  \n   task B at step 3);  \n  \n6) Task B sets fs_info->quota_root to NULL;  \n  \n7) The rescan worker tries to start a transaction and uses  \n   fs_info->quota_root as the root argument for btrfs_start_transaction().  \n   This results in a NULL pointer dereference down the call chain of  \n   btrfs_start_transaction(). The stack trace is something like the one  \n   reported in Link tag below:  \n  \n   general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN  \n   KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]  \n   CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0  \n   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022  \n   Workqueue: btrfs-qgroup-rescan btrfs_work_helper  \n   RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564  \n   Code: 48 89 fb 48 (...)  \n   RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206  \n   RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80  \n   RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000  \n   RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d  \n   R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000  \n   R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003  \n   FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000  \n   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n   CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0  \n   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  \n   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  \n   Call Trace:  \n      \n    btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402  \n    btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280  \n    process_one_work+0x877/0xdb0 kernel/workqueue.c:2289  \n    worker_thread+0xb14/0x1330 kernel/workqueue.c:2436  \n    kthread+0x266/0x300 kernel/kthread.c:376  \n    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308  \n      \n   Modules linked in:  \n  \nSo fix this by having the rescan worker function not attempt to start a  \ntransaction if it didn't do any rescan work. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T09:52:27.000000Z"}, {"uuid": "071e03da-0a7b-4bcf-8f00-ddb8e335341a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-52898", "type": "seen", "source": "https://t.me/cvedetector/3756", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2023-52898 - \"Ubuntu Linux xhci Null Pointer Dereference Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2023-52898 \nPublished : Aug. 21, 2024, 7:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nxhci: Fix null pointer dereference when host dies  \n  \nMake sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race  \nand cause null pointer dereference when host suddenly dies.  \n  \nUsb core may call xhci_free_dev() which frees the xhci->devs[slot_id]  \nvirt device at the same time that xhci_kill_endpoint_urbs() tries to  \nloop through all the device's endpoints, checking if there are any  \ncancelled urbs left to give back.  \n  \nhold the xhci spinlock while freeing the virt device \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T09:52:22.000000Z"}, {"uuid": "6ae31ffa-6afe-44f9-ac88-b196f14b24b6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-52899", "type": "seen", "source": "https://t.me/cvedetector/3747", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2023-52899 - Linux Kernel AXI Chan Handle Err Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2023-52899 \nPublished : Aug. 21, 2024, 7:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nAdd exception protection processing for vd in axi_chan_handle_err function  \n  \nSince there is no protection for vd, a kernel panic will be  \ntriggered here in exceptional cases.  \n  \nYou can refer to the processing of axi_chan_block_xfer_complete function  \n  \nThe triggered kernel panic is as follows:  \n  \n[   67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060  \n[   67.848447] Mem abort info:  \n[   67.848449]   ESR = 0x96000004  \n[   67.848451]   EC = 0x25: DABT (current EL), IL = 32 bits  \n[   67.848454]   SET = 0, FnV = 0  \n[   67.848456]   EA = 0, S1PTW = 0  \n[   67.848458] Data abort info:  \n[   67.848460]   ISV = 0, ISS = 0x00000004  \n[   67.848462]   CM = 0, WnR = 0  \n[   67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000  \n[   67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000  \n[   67.848472] Internal error: Oops: 96000004 [#1] SMP  \n[   67.848475] Modules linked in: dmatest  \n[   67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11  \n[   67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)  \n[   67.848487] pc : axi_chan_handle_err+0xc4/0x230  \n[   67.848491] lr : axi_chan_handle_err+0x30/0x230  \n[   67.848493] sp : ffff0803fe55ae50  \n[   67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200  \n[   67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080  \n[   67.848504] x25: ffff800010d33880 x24: ffff80001139d850  \n[   67.848508] x23: ffff0800c097c168 x22: 0000000000000000  \n[   67.848512] x21: 0000000000000080 x20: 0000000000002000  \n[   67.848517] x19: ffff0800c097c080 x18: 0000000000000000  \n[   67.848521] x17: 0000000000000000 x16: 0000000000000000  \n[   67.848525] x15: 0000000000000000 x14: 0000000000000000  \n[   67.848529] x13: 0000000000000000 x12: 0000000000000040  \n[   67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a  \n[   67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270  \n[   67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0  \n[   67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480  \n[   67.848550] x3 : dead000000000100 x2 : dead000000000122  \n[   67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168  \n[   67.848559] Call trace:  \n[   67.848562]  axi_chan_handle_err+0xc4/0x230  \n[   67.848566]  dw_axi_dma_interrupt+0xf4/0x590  \n[   67.848569]  __handle_irq_event_percpu+0x60/0x220  \n[   67.848573]  handle_irq_event+0x64/0x120  \n[   67.848576]  handle_fasteoi_irq+0xc4/0x220  \n[   67.848580]  __handle_domain_irq+0x80/0xe0  \n[   67.848583]  gic_handle_irq+0xc0/0x138  \n[   67.848585]  el1_irq+0xc8/0x180  \n[   67.848588]  arch_cpu_idle+0x14/0x2c  \n[   67.848591]  default_idle_call+0x40/0x16c  \n[   67.848594]  do_idle+0x1f0/0x250  \n[   67.848597]  cpu_startup_entry+0x2c/0x60  \n[   67.848600]  rest_init+0xc0/0xcc  \n[   67.848603]  arch_call_rest_init+0x14/0x1c  \n[   67.848606]  start_kernel+0x4cc/0x500  \n[   67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)  \n[   67.848613] ---[ end trace 585a97036f88203a ]--- \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T09:52:12.000000Z"}, {"uuid": "ab92933a-3c72-4106-9556-3a285b16f919", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-52895", "type": "seen", "source": "https://t.me/cvedetector/3749", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2023-52895 - Linux Kernel io_uring Poll Multipurpose Buffer Leak\", \n  \"Content\": \"CVE ID : CVE-2023-52895 \nPublished : Aug. 21, 2024, 7:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nio_uring/poll: don't reissue in case of poll race on multishot request  \n  \nA previous commit fixed a poll race that can occur, but it's only  \napplicable for multishot requests. For a multishot request, we can safely  \nignore a spurious wakeup, as we never leave the waitqueue to begin with.  \n  \nA blunt reissue of a multishot armed request can cause us to leak a  \nbuffer, if they are ring provided. While this seems like a bug in itself,  \nit's not really defined behavior to reissue a multishot request directly.  \nIt's less efficient to do so as well, and not required to rearm anything  \nlike it is for singleshot poll requests. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T09:52:14.000000Z"}, {"uuid": "c9309f20-9968-4497-864a-fcfb92cc7fb8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-52897", "type": "seen", "source": "https://t.me/cvedetector/3744", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2023-52897 - btrfs GOOS BUG\", \n  \"Content\": \"CVE ID : CVE-2023-52897 \nPublished : Aug. 21, 2024, 7:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbtrfs: qgroup: do not warn on record without old_roots populated  \n  \n[BUG]  \nThere are some reports from the mailing list that since v6.1 kernel, the  \nWARN_ON() inside btrfs_qgroup_account_extent() gets triggered during  \nrescan:  \n  \n  WARNING: CPU: 3 PID: 6424 at fs/btrfs/qgroup.c:2756 btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]  \n  CPU: 3 PID: 6424 Comm: snapperd Tainted: P           OE      6.1.2-1-default #1 openSUSE Tumbleweed 05c7a1b1b61d5627475528f71f50444637b5aad7  \n  RIP: 0010:btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]  \n  Call Trace:  \n     \n  btrfs_commit_transaction+0x30c/0xb40 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]  \n   ? start_transaction+0xc3/0x5b0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]  \n  btrfs_qgroup_rescan+0x42/0xc0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]  \n   btrfs_ioctl+0x1ab9/0x25c0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]  \n   ? __rseq_handle_notify_resume+0xa9/0x4a0  \n   ? mntput_no_expire+0x4a/0x240  \n   ? __seccomp_filter+0x319/0x4d0  \n   __x64_sys_ioctl+0x90/0xd0  \n   do_syscall_64+0x5b/0x80  \n   ? syscall_exit_to_user_mode+0x17/0x40  \n   ? do_syscall_64+0x67/0x80  \n  entry_SYSCALL_64_after_hwframe+0x63/0xcd  \n  RIP: 0033:0x7fd9b790d9bf  \n     \n  \n[CAUSE]  \nSince commit e15e9f43c7ca (\"btrfs: introduce  \nBTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting\"), if  \nour qgroup is already in inconsistent state, we will no longer do the  \ntime-consuming backref walk.  \n  \nThis can leave some qgroup records without a valid old_roots ulist.  \nNormally this is fine, as btrfs_qgroup_account_extents() would also skip  \nthose records if we have NO_ACCOUNTING flag set.  \n  \nBut there is a small window, if we have NO_ACCOUNTING flag set, and  \ninserted some qgroup_record without a old_roots ulist, but then the user  \ntriggered a qgroup rescan.  \n  \nDuring btrfs_qgroup_rescan(), we firstly clear NO_ACCOUNTING flag, then  \ncommit current transaction.  \n  \nAnd since we have a qgroup_record with old_roots = NULL, we trigger the  \nWARN_ON() during btrfs_qgroup_account_extents().  \n  \n[FIX]  \nUnfortunately due to the introduction of NO_ACCOUNTING flag, the  \nassumption that every qgroup_record would have its old_roots populated  \nis no longer correct.  \n  \nFix the false alerts and drop the WARN_ON(). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-21T09:52:07.000000Z"}]}