diff --git a/advisories/unreviewed/2024/02/GHSA-4hg3-pc9r-pp32/GHSA-4hg3-pc9r-pp32.json b/advisories/unreviewed/2024/02/GHSA-4hg3-pc9r-pp32/GHSA-4hg3-pc9r-pp32.json index 1a03779bf3a..c88157dadb2 100644 --- a/advisories/unreviewed/2024/02/GHSA-4hg3-pc9r-pp32/GHSA-4hg3-pc9r-pp32.json +++ b/advisories/unreviewed/2024/02/GHSA-4hg3-pc9r-pp32/GHSA-4hg3-pc9r-pp32.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-4hg3-pc9r-pp32", - "modified": "2024-02-28T09:30:37Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-02-28T09:30:37Z", "aliases": [ "CVE-2021-46992" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nftables: avoid overflows in nft_hash_buckets()\n\nNumber of buckets being stored in 32bit variables, we have to\nensure that no overflows occur in nft_hash_buckets()\n\nsyzbot injected a size == 0x40000000 and reported:\n\nUBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13\nshift exponent 64 is too large for 64-bit type 'long unsigned int'\nCPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nCall Trace:\n __dump_stack lib/dump_stack.c:79 [inline]\n dump_stack+0x141/0x1d7 lib/dump_stack.c:120\n ubsan_epilogue+0xb/0x5a lib/ubsan.c:148\n __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327\n __roundup_pow_of_two include/linux/log2.h:57 [inline]\n nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline]\n nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652\n nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline]\n nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322\n nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488\n nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline]\n nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630\n netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]\n netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338\n netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927\n sock_sendmsg_nosec net/socket.c:654 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:674\n ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350\n ___sys_sendmsg+0xf3/0x170 net/socket.c:2404\n __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433\n do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -44,8 +49,10 @@ } ], "database_specific": { - "cwe_ids": [], - "severity": null, + "cwe_ids": [ + "CWE-125" + ], + "severity": "HIGH", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-02-28T09:15:37Z" diff --git a/advisories/unreviewed/2024/02/GHSA-9p5f-hx26-h2xq/GHSA-9p5f-hx26-h2xq.json b/advisories/unreviewed/2024/02/GHSA-9p5f-hx26-h2xq/GHSA-9p5f-hx26-h2xq.json index 93b07dcb8e2..4724cb217c4 100644 --- a/advisories/unreviewed/2024/02/GHSA-9p5f-hx26-h2xq/GHSA-9p5f-hx26-h2xq.json +++ b/advisories/unreviewed/2024/02/GHSA-9p5f-hx26-h2xq/GHSA-9p5f-hx26-h2xq.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-9p5f-hx26-h2xq", - "modified": "2024-02-28T09:30:37Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-02-28T09:30:37Z", "aliases": [ "CVE-2021-46997" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: entry: always set GIC_PRIO_PSR_I_SET during entry\n\nZenghui reports that booting a kernel with \"irqchip.gicv3_pseudo_nmi=1\"\non the command line hits a warning during kernel entry, due to the way\nwe manipulate the PMR.\n\nEarly in the entry sequence, we call lockdep_hardirqs_off() to inform\nlockdep that interrupts have been masked (as the HW sets DAIF wqhen\nentering an exception). Architecturally PMR_EL1 is not affected by\nexception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in\nthe exception entry sequence, so early in exception entry the PMR can\nindicate that interrupts are unmasked even though they are masked by\nDAIF.\n\nIf DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that\ninterrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the\nexception entry paths, and hence lockdep_hardirqs_off() will WARN() that\nsomething is amiss.\n\nWe can avoid this by consistently setting GIC_PRIO_PSR_I_SET during\nexception entry so that kernel code sees a consistent environment. We\nmust also update local_daif_inherit() to undo this, as currently only\ntouches DAIF. For other paths, local_daif_restore() will update both\nDAIF and the PMR. With this done, we can remove the existing special\ncases which set this later in the entry code.\n\nWe always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with\nlocal_daif_save(), as this will warn if it ever encounters\n(GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This\nmatches the gic_prio_kentry_setup that we have to retain for\nret_to_user.\n\nThe original splat from Zenghui's report was:\n\n| DEBUG_LOCKS_WARN_ON(!irqs_disabled())\n| WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8\n| Modules linked in:\n| CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463\n| Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n| pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)\n| pc : lockdep_hardirqs_off+0xd4/0xe8\n| lr : lockdep_hardirqs_off+0xd4/0xe8\n| sp : ffff80002a39bad0\n| pmr_save: 000000e0\n| x29: ffff80002a39bad0 x28: ffff0000de214bc0\n| x27: ffff0000de1c0400 x26: 000000000049b328\n| x25: 0000000000406f30 x24: ffff0000de1c00a0\n| x23: 0000000020400005 x22: ffff8000105f747c\n| x21: 0000000096000044 x20: 0000000000498ef9\n| x19: ffff80002a39bc88 x18: ffffffffffffffff\n| x17: 0000000000000000 x16: ffff800011c61eb0\n| x15: ffff800011700a88 x14: 0720072007200720\n| x13: 0720072007200720 x12: 0720072007200720\n| x11: 0720072007200720 x10: 0720072007200720\n| x9 : ffff80002a39bad0 x8 : ffff80002a39bad0\n| x7 : ffff8000119f0800 x6 : c0000000ffff7fff\n| x5 : ffff8000119f07a8 x4 : 0000000000000001\n| x3 : 9bcdab23f2432800 x2 : ffff800011730538\n| x1 : 9bcdab23f2432800 x0 : 0000000000000000\n| Call trace:\n| lockdep_hardirqs_off+0xd4/0xe8\n| enter_from_kernel_mode.isra.5+0x7c/0xa8\n| el1_abort+0x24/0x100\n| el1_sync_handler+0x80/0xd0\n| el1_sync+0x6c/0x100\n| __arch_clear_user+0xc/0x90\n| load_elf_binary+0x9fc/0x1450\n| bprm_execve+0x404/0x880\n| kernel_execve+0x180/0x188\n| call_usermodehelper_exec_async+0xdc/0x158\n| ret_from_fork+0x10/0x18", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -33,7 +38,7 @@ ], "database_specific": { "cwe_ids": [], - "severity": null, + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-02-28T09:15:38Z" diff --git a/advisories/unreviewed/2024/02/GHSA-gwvc-g8fg-56vx/GHSA-gwvc-g8fg-56vx.json b/advisories/unreviewed/2024/02/GHSA-gwvc-g8fg-56vx/GHSA-gwvc-g8fg-56vx.json index fa756813583..6d22253e24e 100644 --- a/advisories/unreviewed/2024/02/GHSA-gwvc-g8fg-56vx/GHSA-gwvc-g8fg-56vx.json +++ b/advisories/unreviewed/2024/02/GHSA-gwvc-g8fg-56vx/GHSA-gwvc-g8fg-56vx.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-gwvc-g8fg-56vx", - "modified": "2024-02-28T09:30:37Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-02-28T09:30:37Z", "aliases": [ "CVE-2021-46993" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix out-of-bound access in uclamp\n\nUtil-clamp places tasks in different buckets based on their clamp values\nfor performance reasons. However, the size of buckets is currently\ncomputed using a rounding division, which can lead to an off-by-one\nerror in some configurations.\n\nFor instance, with 20 buckets, the bucket size will be 1024/20=51. A\ntask with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly,\ncorrect indexes are in range [0,19], hence leading to an out of bound\nmemory access.\n\nClamp the bucket id to fix the issue.", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -36,8 +41,10 @@ } ], "database_specific": { - "cwe_ids": [], - "severity": null, + "cwe_ids": [ + "CWE-125" + ], + "severity": "HIGH", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-02-28T09:15:37Z" diff --git a/advisories/unreviewed/2024/02/GHSA-qg29-4gg5-8r2w/GHSA-qg29-4gg5-8r2w.json b/advisories/unreviewed/2024/02/GHSA-qg29-4gg5-8r2w/GHSA-qg29-4gg5-8r2w.json index af759201819..6f62a5eedf8 100644 --- a/advisories/unreviewed/2024/02/GHSA-qg29-4gg5-8r2w/GHSA-qg29-4gg5-8r2w.json +++ b/advisories/unreviewed/2024/02/GHSA-qg29-4gg5-8r2w/GHSA-qg29-4gg5-8r2w.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-qg29-4gg5-8r2w", - "modified": "2024-02-28T09:30:37Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-02-28T09:30:37Z", "aliases": [ "CVE-2021-46990" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/64s: Fix crashes when toggling entry flush barrier\n\nThe entry flush mitigation can be enabled/disabled at runtime via a\ndebugfs file (entry_flush), which causes the kernel to patch itself to\nenable/disable the relevant mitigations.\n\nHowever depending on which mitigation we're using, it may not be safe to\ndo that patching while other CPUs are active. For example the following\ncrash:\n\n sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20\n\nShows that we returned to userspace with a corrupted LR that points into\nthe kernel, due to executing the partially patched call to the fallback\nentry flush (ie. we missed the LR restore).\n\nFix it by doing the patching under stop machine. The CPUs that aren't\ndoing the patching will be spinning in the core of the stop machine\nlogic. That is currently sufficient for our purposes, because none of\nthe patching we do is to that code or anywhere in the vicinity.", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -53,7 +58,7 @@ ], "database_specific": { "cwe_ids": [], - "severity": null, + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-02-28T09:15:37Z" diff --git a/advisories/unreviewed/2024/02/GHSA-w36p-947m-7c32/GHSA-w36p-947m-7c32.json b/advisories/unreviewed/2024/02/GHSA-w36p-947m-7c32/GHSA-w36p-947m-7c32.json index f83ac3e3c66..b234d7a17cc 100644 --- a/advisories/unreviewed/2024/02/GHSA-w36p-947m-7c32/GHSA-w36p-947m-7c32.json +++ b/advisories/unreviewed/2024/02/GHSA-w36p-947m-7c32/GHSA-w36p-947m-7c32.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-w36p-947m-7c32", - "modified": "2024-02-28T09:30:37Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-02-28T09:30:37Z", "aliases": [ "CVE-2021-46988" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nuserfaultfd: release page in error path to avoid BUG_ON\n\nConsider the following sequence of events:\n\n1. Userspace issues a UFFD ioctl, which ends up calling into\n shmem_mfill_atomic_pte(). We successfully account the blocks, we\n shmem_alloc_page(), but then the copy_from_user() fails. We return\n -ENOENT. We don't release the page we allocated.\n2. Our caller detects this error code, tries the copy_from_user() after\n dropping the mmap_lock, and retries, calling back into\n shmem_mfill_atomic_pte().\n3. Meanwhile, let's say another process filled up the tmpfs being used.\n4. So shmem_mfill_atomic_pte() fails to account blocks this time, and\n immediately returns - without releasing the page.\n\nThis triggers a BUG_ON in our caller, which asserts that the page\nshould always be consumed, unless -ENOENT is returned.\n\nTo fix this, detect if we have such a \"dangling\" page when accounting\nfails, and if so, release it before returning.", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -44,8 +49,10 @@ } ], "database_specific": { - "cwe_ids": [], - "severity": null, + "cwe_ids": [ + "CWE-416" + ], + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-02-28T09:15:37Z" diff --git a/advisories/unreviewed/2024/11/GHSA-cqg5-xfgj-qvgx/GHSA-cqg5-xfgj-qvgx.json b/advisories/unreviewed/2024/11/GHSA-cqg5-xfgj-qvgx/GHSA-cqg5-xfgj-qvgx.json index 7017b69b685..ca3361eabc5 100644 --- a/advisories/unreviewed/2024/11/GHSA-cqg5-xfgj-qvgx/GHSA-cqg5-xfgj-qvgx.json +++ b/advisories/unreviewed/2024/11/GHSA-cqg5-xfgj-qvgx/GHSA-cqg5-xfgj-qvgx.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-cqg5-xfgj-qvgx", - "modified": "2024-11-21T21:33:32Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-11-21T21:33:32Z", "aliases": [ "CVE-2024-53089" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: KVM: Mark hrtimer to expire in hard interrupt context\n\nLike commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard\ninterrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the\ntimer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels\nunmarked hrtimers are moved into soft interrupt expiry mode by default.\nThen the timers are canceled from an preempt-notifier which is invoked\nwith disabled preemption which is not allowed on PREEMPT_RT.\n\nThe timer callback is short so in could be invoked in hard-IRQ context.\nSo let the timer expire on hard-IRQ context even on -RT.\n\nThis fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels:\n\n BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002\n Modules linked in: amdgpu rfkill 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 ns\n CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774\n Tainted: [W]=WARN\n Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022\n Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000\n 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830\n 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001\n 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140\n 00000000000003fe 0000000000000001 000000000000000d 0000000000000003\n 0000000000000030 00000000000003f3 000000000790c000 9000000116747830\n 90000000057ef000 0000000000000000 9000000005644830 0000000000000004\n 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868\n 900000000451b600 9000000005644830 9000000003a13998 0000000010000020\n 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d\n ...\n Call Trace:\n [<9000000003a13998>] show_stack+0x38/0x180\n [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0\n [<9000000003a71708>] __schedule_bug+0x48/0x60\n [<9000000004e45734>] __schedule+0x1114/0x1660\n [<9000000004e46040>] schedule_rtlock+0x20/0x60\n [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0\n [<9000000004e4f038>] rt_spin_lock+0x58/0x80\n [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0\n [<9000000003b02e30>] hrtimer_cancel+0x70/0x80\n [] kvm_restore_timer+0x50/0x1a0 [kvm]\n [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm]\n [] kvm_sched_in+0x34/0x60 [kvm]\n [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0\n [<9000000004e44a70>] __schedule+0x450/0x1660\n [<9000000004e45cb0>] schedule+0x30/0x180\n [] kvm_vcpu_block+0x70/0x120 [kvm]\n [] kvm_vcpu_halt+0x60/0x3e0 [kvm]\n [] kvm_handle_gspr+0x3f4/0x4e0 [kvm]\n [] kvm_handle_exit+0x1c8/0x260 [kvm]", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -25,7 +30,7 @@ ], "database_specific": { "cwe_ids": [], - "severity": null, + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-11-21T19:15:11Z" diff --git a/advisories/unreviewed/2024/11/GHSA-f3pg-hppr-jf6f/GHSA-f3pg-hppr-jf6f.json b/advisories/unreviewed/2024/11/GHSA-f3pg-hppr-jf6f/GHSA-f3pg-hppr-jf6f.json index 1d9c3a7a998..40adf9732bf 100644 --- a/advisories/unreviewed/2024/11/GHSA-f3pg-hppr-jf6f/GHSA-f3pg-hppr-jf6f.json +++ b/advisories/unreviewed/2024/11/GHSA-f3pg-hppr-jf6f/GHSA-f3pg-hppr-jf6f.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-f3pg-hppr-jf6f", - "modified": "2024-11-21T21:33:32Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-11-21T21:33:32Z", "aliases": [ "CVE-2024-53090" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix lock recursion\n\nafs_wake_up_async_call() can incur lock recursion. The problem is that it\nis called from AF_RXRPC whilst holding the ->notify_lock, but it tries to\ntake a ref on the afs_call struct in order to pass it to a work queue - but\nif the afs_call is already queued, we then have an extraneous ref that must\nbe put... calling afs_put_call() may call back down into AF_RXRPC through\nrxrpc_kernel_shutdown_call(), however, which might try taking the\n->notify_lock again.\n\nThis case isn't very common, however, so defer it to a workqueue. The oops\nlooks something like:\n\n BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646\n lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0\n CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351\n Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014\n Call Trace:\n \n dump_stack_lvl+0x47/0x70\n do_raw_spin_lock+0x3c/0x90\n rxrpc_kernel_shutdown_call+0x83/0xb0\n afs_put_call+0xd7/0x180\n rxrpc_notify_socket+0xa0/0x190\n rxrpc_input_split_jumbo+0x198/0x1d0\n rxrpc_input_data+0x14b/0x1e0\n ? rxrpc_input_call_packet+0xc2/0x1f0\n rxrpc_input_call_event+0xad/0x6b0\n rxrpc_input_packet_on_conn+0x1e1/0x210\n rxrpc_input_packet+0x3f2/0x4d0\n rxrpc_io_thread+0x243/0x410\n ? __pfx_rxrpc_io_thread+0x10/0x10\n kthread+0xcf/0xe0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x24/0x40\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n ", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -24,8 +29,10 @@ } ], "database_specific": { - "cwe_ids": [], - "severity": null, + "cwe_ids": [ + "CWE-674" + ], + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-11-21T19:15:12Z" diff --git a/advisories/unreviewed/2024/11/GHSA-p7x7-vrh2-wvvc/GHSA-p7x7-vrh2-wvvc.json b/advisories/unreviewed/2024/11/GHSA-p7x7-vrh2-wvvc/GHSA-p7x7-vrh2-wvvc.json index 36eff171760..44c0321d4ce 100644 --- a/advisories/unreviewed/2024/11/GHSA-p7x7-vrh2-wvvc/GHSA-p7x7-vrh2-wvvc.json +++ b/advisories/unreviewed/2024/11/GHSA-p7x7-vrh2-wvvc/GHSA-p7x7-vrh2-wvvc.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-p7x7-vrh2-wvvc", - "modified": "2024-11-21T21:33:32Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-11-21T21:33:32Z", "aliases": [ "CVE-2024-53092" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_pci: Fix admin vq cleanup by using correct info pointer\n\nvp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq\nresources by virtio_pci_vq_info pointer. The info pointer of admin\nvq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[].\nUsing the info pointer from vp_dev->vqs[] for admin vq causes a\nkernel NULL pointer dereference bug.\nIn vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer\nfrom vp_dev->admin_vq.info for admin vq to clean up the resources.\nAlso make info ptr as argument of vp_del_vq() to be symmetric with\nvp_setup_vq().\n\nvp_reset calls vp_modern_avq_cleanup, and causes the Call Trace:\n==================================================================\nBUG: kernel NULL pointer dereference, address:0000000000000000\n...\nCPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1\nRIP: 0010:vp_reset+0x57/0x90 [virtio_pci]\nCall Trace:\n \n...\n ? vp_reset+0x57/0x90 [virtio_pci]\n ? vp_reset+0x38/0x90 [virtio_pci]\n virtio_reset_device+0x1d/0x30\n remove_vq_common+0x1c/0x1a0 [virtio_net]\n virtnet_remove+0xa1/0xc0 [virtio_net]\n virtio_dev_remove+0x46/0xa0\n...\n virtio_pci_driver_exit+0x14/0x810 [virtio_pci]\n==================================================================", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -24,8 +29,10 @@ } ], "database_specific": { - "cwe_ids": [], - "severity": null, + "cwe_ids": [ + "CWE-476" + ], + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-11-21T19:15:12Z" diff --git a/advisories/unreviewed/2024/11/GHSA-pmfq-rg8w-w57m/GHSA-pmfq-rg8w-w57m.json b/advisories/unreviewed/2024/11/GHSA-pmfq-rg8w-w57m/GHSA-pmfq-rg8w-w57m.json index b196f88b199..6369122c0dc 100644 --- a/advisories/unreviewed/2024/11/GHSA-pmfq-rg8w-w57m/GHSA-pmfq-rg8w-w57m.json +++ b/advisories/unreviewed/2024/11/GHSA-pmfq-rg8w-w57m/GHSA-pmfq-rg8w-w57m.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-pmfq-rg8w-w57m", - "modified": "2024-12-18T09:31:34Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-11-26T00:33:31Z", "aliases": [ "CVE-2024-53096" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: resolve faulty mmap_region() error path behaviour\n\nThe mmap_region() function is somewhat terrifying, with spaghetti-like\ncontrol flow and numerous means by which issues can arise and incomplete\nstate, memory leaks and other unpleasantness can occur.\n\nA large amount of the complexity arises from trying to handle errors late\nin the process of mapping a VMA, which forms the basis of recently\nobserved issues with resource leaks and observable inconsistent state.\n\nTaking advantage of previous patches in this series we move a number of\nchecks earlier in the code, simplifying things by moving the core of the\nlogic into a static internal function __mmap_region().\n\nDoing this allows us to perform a number of checks up front before we do\nany real work, and allows us to unwind the writable unmap check\nunconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE\nvalidation unconditionally also.\n\nWe move a number of things here:\n\n1. We preallocate memory for the iterator before we call the file-backed\n memory hook, allowing us to exit early and avoid having to perform\n complicated and error-prone close/free logic. We carefully free\n iterator state on both success and error paths.\n\n2. The enclosing mmap_region() function handles the mapping_map_writable()\n logic early. Previously the logic had the mapping_map_writable() at the\n point of mapping a newly allocated file-backed VMA, and a matching\n mapping_unmap_writable() on success and error paths.\n\n We now do this unconditionally if this is a file-backed, shared writable\n mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however\n doing so does not invalidate the seal check we just performed, and we in\n any case always decrement the counter in the wrapper.\n\n We perform a debug assert to ensure a driver does not attempt to do the\n opposite.\n\n3. We also move arch_validate_flags() up into the mmap_region()\n function. This is only relevant on arm64 and sparc64, and the check is\n only meaningful for SPARC with ADI enabled. We explicitly add a warning\n for this arch if a driver invalidates this check, though the code ought\n eventually to be fixed to eliminate the need for this.\n\nWith all of these measures in place, we no longer need to explicitly close\nthe VMA on error paths, as we place all checks which might fail prior to a\ncall to any driver mmap hook.\n\nThis eliminates an entire class of errors, makes the code easier to reason\nabout and more robust.", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -41,7 +46,7 @@ ], "database_specific": { "cwe_ids": [], - "severity": null, + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-11-25T22:15:15Z" diff --git a/advisories/unreviewed/2024/11/GHSA-qccg-86w9-x648/GHSA-qccg-86w9-x648.json b/advisories/unreviewed/2024/11/GHSA-qccg-86w9-x648/GHSA-qccg-86w9-x648.json index 8d7a9f678ee..b24e8f2d0b7 100644 --- a/advisories/unreviewed/2024/11/GHSA-qccg-86w9-x648/GHSA-qccg-86w9-x648.json +++ b/advisories/unreviewed/2024/11/GHSA-qccg-86w9-x648/GHSA-qccg-86w9-x648.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-qccg-86w9-x648", - "modified": "2024-11-21T21:33:32Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-11-21T21:33:32Z", "aliases": [ "CVE-2024-53091" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx\n\nAs the introduction of the support for vsock and unix sockets in sockmap,\ntls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK.\nvsock and af_unix sockets have vsock_sock and unix_sock instead of\ninet_connection_sock. For these sockets, tls_get_ctx may return an invalid\npointer and cause page fault in function tls_sw_ctx_rx.\n\nBUG: unable to handle page fault for address: 0000000000040030\nWorkqueue: vsock-loopback vsock_loopback_work\nRIP: 0010:sk_psock_strp_data_ready+0x23/0x60\nCall Trace:\n ? __die+0x81/0xc3\n ? no_context+0x194/0x350\n ? do_page_fault+0x30/0x110\n ? async_page_fault+0x3e/0x50\n ? sk_psock_strp_data_ready+0x23/0x60\n virtio_transport_recv_pkt+0x750/0x800\n ? update_load_avg+0x7e/0x620\n vsock_loopback_work+0xd0/0x100\n process_one_work+0x1a7/0x360\n worker_thread+0x30/0x390\n ? create_worker+0x1a0/0x1a0\n kthread+0x112/0x130\n ? __kthread_cancel_work+0x40/0x40\n ret_from_fork+0x1f/0x40\n\nv2:\n - Add IS_ICSK check\nv3:\n - Update the commits in Fixes", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -29,7 +34,7 @@ ], "database_specific": { "cwe_ids": [], - "severity": null, + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-11-21T19:15:12Z" diff --git a/advisories/unreviewed/2024/11/GHSA-rw6f-qwrg-vhvv/GHSA-rw6f-qwrg-vhvv.json b/advisories/unreviewed/2024/11/GHSA-rw6f-qwrg-vhvv/GHSA-rw6f-qwrg-vhvv.json index fed3ddff2cb..ff6104e9172 100644 --- a/advisories/unreviewed/2024/11/GHSA-rw6f-qwrg-vhvv/GHSA-rw6f-qwrg-vhvv.json +++ b/advisories/unreviewed/2024/11/GHSA-rw6f-qwrg-vhvv/GHSA-rw6f-qwrg-vhvv.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-rw6f-qwrg-vhvv", - "modified": "2024-11-21T21:33:32Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-11-21T21:33:32Z", "aliases": [ "CVE-2024-53093" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-multipath: defer partition scanning\n\nWe need to suppress the partition scan from occuring within the\ncontroller's scan_work context. If a path error occurs here, the IO will\nwait until a path becomes available or all paths are torn down, but that\naction also occurs within scan_work, so it would deadlock. Defer the\npartion scan to a different context that does not block scan_work.", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -33,7 +38,7 @@ ], "database_specific": { "cwe_ids": [], - "severity": null, + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-11-21T19:15:12Z" diff --git a/advisories/unreviewed/2024/11/GHSA-w7c6-4vwf-466q/GHSA-w7c6-4vwf-466q.json b/advisories/unreviewed/2024/11/GHSA-w7c6-4vwf-466q/GHSA-w7c6-4vwf-466q.json index bd560c6a880..f746f6cab74 100644 --- a/advisories/unreviewed/2024/11/GHSA-w7c6-4vwf-466q/GHSA-w7c6-4vwf-466q.json +++ b/advisories/unreviewed/2024/11/GHSA-w7c6-4vwf-466q/GHSA-w7c6-4vwf-466q.json @@ -1,13 +1,18 @@ { "schema_version": "1.4.0", "id": "GHSA-w7c6-4vwf-466q", - "modified": "2024-11-21T21:33:32Z", + "modified": "2024-12-24T15:30:31Z", "published": "2024-11-21T21:33:32Z", "aliases": [ "CVE-2024-53094" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES\n\nWhile running ISER over SIW, the initiator machine encounters a warning\nfrom skb_splice_from_iter() indicating that a slab page is being used in\nsend_page. To address this, it is better to add a sendpage_ok() check\nwithin the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag\nshould be disabled before entering the network stack.\n\nA similar issue has been discussed for NVMe in this thread:\nhttps://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/\n\n WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320\n Call Trace:\n tcp_sendmsg_locked+0x368/0xe40\n siw_tx_hdt+0x695/0xa40 [siw]\n siw_qp_sq_process+0x102/0xb00 [siw]\n siw_sq_resume+0x39/0x110 [siw]\n siw_run_sq+0x74/0x160 [siw]\n kthread+0xd2/0x100\n ret_from_fork+0x34/0x40\n ret_from_fork_asm+0x1a/0x30", - "severity": [], + "severity": [ + { + "type": "CVSS_V3", + "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" + } + ], "affected": [], "references": [ { @@ -29,7 +34,7 @@ ], "database_specific": { "cwe_ids": [], - "severity": null, + "severity": "MODERATE", "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-11-21T19:15:12Z"