Advisory Database Sync

This commit is contained in:
advisory-database[bot]
2025-01-08 18:32:35 +00:00
parent 9132f4da71
commit 63ede572cb
133 changed files with 1995 additions and 281 deletions
@@ -26,7 +26,8 @@
],
"database_specific": {
"cwe_ids": [
"CWE-269"
"CWE-269",
"CWE-863"
],
"severity": "HIGH",
"github_reviewed": false,
@@ -1,7 +1,7 @@
{
"schema_version": "1.4.0",
"id": "GHSA-wf52-5wvv-68vv",
"modified": "2023-11-25T12:30:22Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2023-06-07T21:30:18Z",
"aliases": [
"CVE-2023-33864"
@@ -1,7 +1,7 @@
{
"schema_version": "1.4.0",
"id": "GHSA-gp56-58fv-r42c",
"modified": "2023-11-18T00:30:17Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2023-11-14T06:30:19Z",
"aliases": [
"CVE-2023-43902"
@@ -25,7 +25,9 @@
}
],
"database_specific": {
"cwe_ids": [],
"cwe_ids": [
"CWE-276"
],
"severity": "CRITICAL",
"github_reviewed": false,
"github_reviewed_at": null,
@@ -1,7 +1,7 @@
{
"schema_version": "1.4.0",
"id": "GHSA-r526-pvv3-w6p8",
"modified": "2023-11-18T00:30:17Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2023-11-14T06:30:19Z",
"aliases": [
"CVE-2023-45878"
@@ -25,7 +25,9 @@
}
],
"database_specific": {
"cwe_ids": [],
"cwe_ids": [
"CWE-787"
],
"severity": "CRITICAL",
"github_reviewed": false,
"github_reviewed_at": null,
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-5fx7-qfg5-mpmc",
"modified": "2024-02-27T21:31:27Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2024-02-27T21:31:27Z",
"aliases": [
"CVE-2021-46972"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\novl: fix leaked dentry\n\nSince commit 6815f479ca90 (\"ovl: use only uppermetacopy state in\novl_lookup()\"), overlayfs doesn't put temporary dentry when there is a\nmetacopy error, which leads to dentry leaks when shutting down the related\nsuperblock:\n\n overlayfs: refusing to follow metacopy origin for (/file0)\n ...\n BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay]\n ...\n WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d\n CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1\n ...\n RIP: 0010:umount_check.cold+0x107/0x14d\n ...\n Call Trace:\n d_walk+0x28c/0x950\n ? dentry_lru_isolate+0x2b0/0x2b0\n ? __kasan_slab_free+0x12/0x20\n do_one_tree+0x33/0x60\n shrink_dcache_for_umount+0x78/0x1d0\n generic_shutdown_super+0x70/0x440\n kill_anon_super+0x3e/0x70\n deactivate_locked_super+0xc4/0x160\n deactivate_super+0xfa/0x140\n cleanup_mnt+0x22e/0x370\n __cleanup_mnt+0x1a/0x30\n task_work_run+0x139/0x210\n do_exit+0xb0c/0x2820\n ? __kasan_check_read+0x1d/0x30\n ? find_held_lock+0x35/0x160\n ? lock_release+0x1b6/0x660\n ? mm_update_next_owner+0xa20/0xa20\n ? reacquire_held_locks+0x3f0/0x3f0\n ? __sanitizer_cov_trace_const_cmp4+0x22/0x30\n do_group_exit+0x135/0x380\n __do_sys_exit_group.isra.0+0x20/0x20\n __x64_sys_exit_group+0x3c/0x50\n do_syscall_64+0x45/0x70\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n ...\n VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day...\n\nThis fix has been tested with a syzkaller reproducer.",
"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": [
{
@@ -32,8 +37,10 @@
}
],
"database_specific": {
"cwe_ids": [],
"severity": null,
"cwe_ids": [
"CWE-401"
],
"severity": "MODERATE",
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-27T19:04:07Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-92wm-282g-vw3w",
"modified": "2024-02-28T09:30:37Z",
"modified": "2025-01-08T18:30:41Z",
"published": "2024-02-28T09:30:37Z",
"aliases": [
"CVE-2021-47007"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix panic during f2fs_resize_fs()\n\nf2fs_resize_fs() hangs in below callstack with testcase:\n- mkfs 16GB image & mount image\n- dd 8GB fileA\n- dd 8GB fileB\n- sync\n- rm fileA\n- sync\n- resize filesystem to 8GB\n\nkernel BUG at segment.c:2484!\nCall Trace:\n allocate_segment_by_default+0x92/0xf0 [f2fs]\n f2fs_allocate_data_block+0x44b/0x7e0 [f2fs]\n do_write_page+0x5a/0x110 [f2fs]\n f2fs_outplace_write_data+0x55/0x100 [f2fs]\n f2fs_do_write_data_page+0x392/0x850 [f2fs]\n move_data_page+0x233/0x320 [f2fs]\n do_garbage_collect+0x14d9/0x1660 [f2fs]\n free_segment_range+0x1f7/0x310 [f2fs]\n f2fs_resize_fs+0x118/0x330 [f2fs]\n __f2fs_ioctl+0x487/0x3680 [f2fs]\n __x64_sys_ioctl+0x8e/0xd0\n do_syscall_64+0x33/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nThe root cause is we forgot to check that whether we have enough space\nin resized filesystem to store all valid blocks in before-resizing\nfilesystem, then allocator will run out-of-space during block migration\nin free_segment_range().",
"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": [
{
@@ -32,8 +37,10 @@
}
],
"database_specific": {
"cwe_ids": [],
"severity": null,
"cwe_ids": [
"CWE-754"
],
"severity": "MODERATE",
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:38Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-94mv-98xv-9mqq",
"modified": "2024-02-28T09:30:37Z",
"modified": "2025-01-08T18:30:41Z",
"published": "2024-02-28T09:30:37Z",
"aliases": [
"CVE-2021-47014"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ct: fix wild memory access when clearing fragments\n\nwhile testing re-assembly/re-fragmentation using act_ct, it's possible to\nobserve a crash like the following one:\n\n KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f]\n CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S 5.12.0-rc7+ #424\n Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017\n RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0\n Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48\n RSP: 0018:ffff888c31449db8 EFLAGS: 00010203\n RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960\n RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e\n RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350\n R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000\n R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160\n FS: 0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n <IRQ>\n inet_frag_destroy+0xa9/0x150\n call_timer_fn+0x2d/0x180\n run_timer_softirq+0x4fe/0xe70\n __do_softirq+0x197/0x5a0\n irq_exit_rcu+0x1de/0x200\n sysvec_apic_timer_interrupt+0x6b/0x80\n </IRQ>\n\nwhen act_ct temporarily stores an IP fragment, restoring the skb qdisc cb\nresults in putting random data in FRAG_CB(), and this causes those \"wild\"\nmemory accesses later, when the rbtree is purged. Never overwrite the skb\ncb in case tcf_ct_handle_fragments() returns -EINPROGRESS.",
"severity": [],
"severity": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [],
"references": [
{
@@ -24,8 +29,10 @@
}
],
"database_specific": {
"cwe_ids": [],
"severity": null,
"cwe_ids": [
"CWE-754"
],
"severity": "HIGH",
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:38Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-98fc-82jh-j626",
"modified": "2024-02-28T09:30:37Z",
"modified": "2025-01-08T18:30:41Z",
"published": "2024-02-28T09:30:37Z",
"aliases": [
"CVE-2021-47004"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid touching checkpointed data in get_victim()\n\nIn CP disabling mode, there are two issues when using LFS or SSR | AT_SSR\nmode to select victim:\n\n1. LFS is set to find source section during GC, the victim should have\nno checkpointed data, since after GC, section could not be set free for\nreuse.\n\nPreviously, we only check valid chpt blocks in current segment rather\nthan section, fix it.\n\n2. SSR | AT_SSR are set to find target segment for writes which can be\nfully filled by checkpointed and newly written blocks, we should never\nselect such segment, otherwise it can cause panic or data corruption\nduring allocation, potential case is described as below:\n\n a) target segment has 'n' (n < 512) ckpt valid blocks\n b) GC migrates 'n' valid blocks to other segment (segment is still\n in dirty list)\n c) GC migrates '512 - n' blocks to target segment (segment has 'n'\n cp_vblocks and '512 - n' vblocks)\n d) If GC selects target segment via {AT,}SSR allocator, however there\n is no free space in targe segment.",
"severity": [],
"severity": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H"
}
],
"affected": [],
"references": [
{
@@ -33,7 +38,7 @@
],
"database_specific": {
"cwe_ids": [],
"severity": null,
"severity": "HIGH",
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:38Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-c4q6-cxg2-pxc8",
"modified": "2024-02-27T21:31:27Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2024-02-27T21:31:27Z",
"aliases": [
"CVE-2021-46969"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: core: Fix invalid error returning in mhi_queue\n\nmhi_queue returns an error when the doorbell is not accessible in\nthe current state. This can happen when the device is in non M0\nstate, like M3, and needs to be waken-up prior ringing the DB. This\ncase is managed earlier by triggering an asynchronous M3 exit via\ncontroller resume/suspend callbacks, that in turn will cause M0\ntransition and DB update.\n\nSo, since it's not an error but just delaying of doorbell update, there\nis no reason to return an error.\n\nThis also fixes a use after free error for skb case, indeed a caller\nqueuing skb will try to free the skb if the queueing fails, but in\nthat case queueing has been done.",
"severity": [],
"severity": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [],
"references": [
{
@@ -24,8 +29,10 @@
}
],
"database_specific": {
"cwe_ids": [],
"severity": null,
"cwe_ids": [
"CWE-416"
],
"severity": "HIGH",
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-27T19:04:07Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-c4xm-6jcf-xfq6",
"modified": "2024-02-28T09:30:37Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2024-02-28T09:30:37Z",
"aliases": [
"CVE-2021-46999"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: do asoc update earlier in sctp_sf_do_dupcook_a\n\nThere's a panic that occurs in a few of envs, the call trace is as below:\n\n [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI\n [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp]\n [] sctp_assoc_control_transport+0x1b9/0x210 [sctp]\n [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp]\n [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp]\n [] sctp_do_sm+0xc3/0x2a0 [sctp]\n [] sctp_generate_timeout_event+0x81/0xf0 [sctp]\n\nThis is caused by a transport use-after-free issue. When processing a\nduplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK\nand SHUTDOWN chunks are allocated with the transort from the new asoc.\nHowever, later in the sideeffect machine, the old asoc is used to send\nthem out and old asoc's shutdown_last_sent_to is set to the transport\nthat SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually\nbelongs to the new asoc. After the new_asoc is freed and the old asoc\nT2 timeout, the old asoc's shutdown_last_sent_to that is already freed\nwould be accessed in sctp_sf_t2_timer_expire().\n\nThanks Alexander and Jere for helping dig into this issue.\n\nTo fix it, this patch is to do the asoc update first, then allocate\nthe COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This\nwould make more sense, as a chunk from an asoc shouldn't be sent out\nwith another asoc. We had fixed quite a few issues caused by this.",
"severity": [],
"severity": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [],
"references": [
{
@@ -40,8 +45,10 @@
}
],
"database_specific": {
"cwe_ids": [],
"severity": null,
"cwe_ids": [
"CWE-416"
],
"severity": "HIGH",
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:38Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-gc58-f6gq-w9xv",
"modified": "2024-02-28T09:30:38Z",
"modified": "2025-01-08T18:30:41Z",
"published": "2024-02-28T09:30:38Z",
"aliases": [
"CVE-2021-47019"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7921: fix possible invalid register access\n\nDisable the interrupt and synchronze for the pending irq handlers to ensure\nthe irq tasklet is not being scheduled after the suspend to avoid the\npossible invalid register access acts when the host pcie controller is\nsuspended.\n\n[17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs\n[17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00\n[17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs\n[17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc\n[17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs\n\n...\n\n17933.615352] x1 : 00000000000d4200 x0 : ffffff8269ca2300\n[17933.620666] Call trace:\n[17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76]\n[17933.627234] mt7921_rr+0x38/0x44 [mt7921e]\n[17933.631339] mt7921_irq_tasklet+0x54/0x1d8 [mt7921e]\n[17933.636309] tasklet_action_common+0x12c/0x16c\n[17933.640754] tasklet_action+0x24/0x2c\n[17933.644418] __do_softirq+0x16c/0x344\n[17933.648082] irq_exit+0xa8/0xac\n[17933.651224] scheduler_ipi+0xd4/0x148\n[17933.654890] handle_IPI+0x164/0x2d4\n[17933.658379] gic_handle_irq+0x140/0x178\n[17933.662216] el1_irq+0xb8/0x180\n[17933.665361] cpuidle_enter_state+0xf8/0x204\n[17933.669544] cpuidle_enter+0x38/0x4c\n[17933.673122] do_idle+0x1a4/0x2a8\n[17933.676352] cpu_startup_entry+0x24/0x28\n[17933.680276] rest_init+0xd4/0xe0\n[17933.683508] arch_call_rest_init+0x10/0x18\n[17933.687606] start_kernel+0x340/0x3b4\n[17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113)\n[17933.697373] ---[ end trace a24b8e26ffbda3c5 ]---\n[17933.767846] Kernel panic - not syncing: Fatal exception in interrupt",
"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-02-28T09:15:39Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-h3qj-j9m5-8ffr",
"modified": "2024-02-28T09:30:37Z",
"modified": "2025-01-08T18:30:41Z",
"published": "2024-02-28T09:30:37Z",
"aliases": [
"CVE-2021-47001"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Fix cwnd update ordering\n\nAfter a reconnect, the reply handler is opening the cwnd (and thus\nenabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs()\ncan post enough Receive WRs to receive their replies. This causes an\nRNR and the new connection is lost immediately.\n\nThe race is most clearly exposed when KASAN and disconnect injection\nare enabled. This slows down rpcrdma_rep_create() enough to allow\nthe send side to post a bunch of RPC Calls before the Receive\ncompletion handler can invoke ib_post_recv().",
"severity": [],
"severity": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:H/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"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-hmgx-rfwx-3mvq",
"modified": "2024-02-27T21:31:27Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2024-02-27T21:31:27Z",
"aliases": [
"CVE-2021-46971"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix unconditional security_locked_down() call\n\nCurrently, the lockdown state is queried unconditionally, even though\nits result is used only if the PERF_SAMPLE_REGS_INTR bit is set in\nattr.sample_type. While that doesn't matter in case of the Lockdown LSM,\nit causes trouble with the SELinux's lockdown hook implementation.\n\nSELinux implements the locked_down hook with a check whether the current\ntask's type has the corresponding \"lockdown\" class permission\n(\"integrity\" or \"confidentiality\") allowed in the policy. This means\nthat calling the hook when the access control decision would be ignored\ngenerates a bogus permission check and audit record.\n\nFix this by checking sample_type first and only calling the hook when\nits result would be honored.",
"severity": [],
"severity": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N"
}
],
"affected": [],
"references": [
{
@@ -37,7 +42,7 @@
],
"database_specific": {
"cwe_ids": [],
"severity": null,
"severity": "LOW",
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-27T19:04:07Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-jfx3-f7mg-7cp3",
"modified": "2024-02-27T21:31:27Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2024-02-27T21:31:27Z",
"aliases": [
"CVE-2021-46970"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue\n\nA recent change created a dedicated workqueue for the state-change work\nwith WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags,\nbut the state-change work (mhi_pm_st_worker) does not guarantee forward\nprogress under memory pressure, and will even wait on various memory\nallocations when e.g. creating devices, loading firmware, etc... The\nwork is then not part of a memory reclaim path...\n\nMoreover, this causes a warning in check_flush_dependency() since we end\nup in code that flushes a non-reclaim workqueue:\n\n[ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog\n[ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140\n[ 40.969733] Call Trace:\n[ 40.969740] __flush_work+0x97/0x1d0\n[ 40.969745] ? wake_up_process+0x15/0x20\n[ 40.969749] ? insert_work+0x70/0x80\n[ 40.969750] ? __queue_work+0x14a/0x3e0\n[ 40.969753] flush_work+0x10/0x20\n[ 40.969756] rollback_registered_many+0x1c9/0x510\n[ 40.969759] unregister_netdevice_queue+0x94/0x120\n[ 40.969761] unregister_netdev+0x1d/0x30\n[ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net]\n[ 40.969770] mhi_driver_remove+0x124/0x250 [mhi]\n[ 40.969776] device_release_driver_internal+0xf0/0x1d0\n[ 40.969778] device_release_driver+0x12/0x20\n[ 40.969782] bus_remove_device+0xe1/0x150\n[ 40.969786] device_del+0x17b/0x3e0\n[ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi]\n[ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi]\n[ 40.969799] device_for_each_child+0x5e/0xa0\n[ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]",
"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-02-27T19:04:07Z"
File diff suppressed because one or more lines are too long
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-m99h-2hm4-q649",
"modified": "2024-02-28T09:30:36Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2024-02-28T09:30:36Z",
"aliases": [
"CVE-2021-46977"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: VMX: Disable preemption when probing user return MSRs\n\nDisable preemption when probing a user return MSR via RDSMR/WRMSR. If\nthe MSR holds a different value per logical CPU, the WRMSR could corrupt\nthe host's value if KVM is preempted between the RDMSR and WRMSR, and\nthen rescheduled on a different CPU.\n\nOpportunistically land the helper in common x86, SVM will use the helper\nin a future commit.",
"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:37Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-mvm9-g6f5-rfmr",
"modified": "2024-02-28T09:30:38Z",
"modified": "2025-01-08T18:30:41Z",
"published": "2024-02-28T09:30:37Z",
"aliases": [
"CVE-2021-47015"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix RX consumer index logic in the error path.\n\nIn bnxt_rx_pkt(), the RX buffers are expected to complete in order.\nIf the RX consumer index indicates an out of order buffer completion,\nit means we are hitting a hardware bug and the driver will abort all\nremaining RX packets and reset the RX ring. The RX consumer index\nthat we pass to bnxt_discard_rx() is not correct. We should be\npassing the current index (tmp_raw_cons) instead of the old index\n(raw_cons). This bug can cause us to be at the wrong index when\ntrying to abort the next RX packet. It can crash like this:\n\n #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007\n #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232\n #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e\n #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978\n #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0\n #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e\n #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24\n #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e\n #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12\n #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5\n [exception RIP: bnxt_rx_pkt+237]\n RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213\n RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000\n RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000\n RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d\n R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0\n R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000\n ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018",
"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": [
{
@@ -37,7 +42,7 @@
],
"database_specific": {
"cwe_ids": [],
"severity": null,
"severity": "MODERATE",
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:38Z"
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-p768-cw2x-34vr",
"modified": "2024-02-28T09:30:38Z",
"modified": "2025-01-08T18:30:41Z",
"published": "2024-02-28T09:30:37Z",
"aliases": [
"CVE-2021-47018"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/64: Fix the definition of the fixmap area\n\nAt the time being, the fixmap area is defined at the top of\nthe address space or just below KASAN.\n\nThis definition is not valid for PPC64.\n\nFor PPC64, use the top of the I/O space.\n\nBecause of circular dependencies, it is not possible to include\nasm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size\nAREA at the top of the I/O space for fixmap and ensure during\nbuild that the size is big enough.",
"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:39Z"
File diff suppressed because one or more lines are too long
@@ -1,13 +1,18 @@
{
"schema_version": "1.4.0",
"id": "GHSA-q466-f768-77v8",
"modified": "2024-02-27T21:31:27Z",
"modified": "2025-01-08T18:30:40Z",
"published": "2024-02-27T21:31:27Z",
"aliases": [
"CVE-2021-46965"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: physmap: physmap-bt1-rom: Fix unintentional stack access\n\nCast &data to (char *) in order to avoid unintentionally accessing\nthe stack.\n\nNotice that data is of type u32, so any increment to &data\nwill be in the order of 4-byte chunks, and this piece of code\nis actually intended to be a byte offset.\n\nAddresses-Coverity-ID: 1497765 (\"Out-of-bounds access\")",
"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": [
{
@@ -32,8 +37,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-27T19:04:07Z"

Some files were not shown because too many files have changed in this diff Show More