Logo
-

Byte Open Security

(ByteOS Network)

Log In

Sign Up

ByteOS

Security
Vulnerability Details
Registries
Custom Views
Weaknesses
Attack Patterns
Filters & Tools
Vulnerability Details :

CVE-2025-21932

Summary
Assigner-Linux
Assigner Org ID-416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published At-01 Apr, 2025 | 15:41
Updated At-11 May, 2026 | 21:09
Rejected At-
Credits

mm: abort vma_modify() on merge out of memory failure

In the Linux kernel, the following vulnerability has been resolved: mm: abort vma_modify() on merge out of memory failure The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt. Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values. Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e. the kernel would simply keep retrying reclaim until it succeeded. However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!). Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early. So there is no doubt it is appropriate to simply bail out in this scenario. However, in general we must if at all possible never assume VMG state is stable after a merge attempt, since merge operations update VMG fields. As a result, additionally also make this clear by storing start, end in local variables. The issue was reported originally by syzkaller, and by Brad Spengler (via an off-list discussion), and in both instances it manifested as a triggering of the assert: VM_WARN_ON_VMG(start >= end, vmg); In vma_merge_existing_range(). It seems at least one scenario in which this is occurring is one in which the merge being attempted is due to an madvise() across multiple VMAs which looks like this: start end |<------>| |----------|------| | vma | next | |----------|------| When madvise_walk_vmas() is invoked, we first find vma in the above (determining prev to be equal to vma as we are offset into vma), and then enter the loop. We determine the end of vma that forms part of the range we are madvise()'ing by setting 'tmp' to this value: /* Here vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; We then invoke the madvise() operation via visit(), letting prev get updated to point to vma as part of the operation: /* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Where the visit() function pointer in this instance is madvise_vma_behavior(). As observed in syzkaller reports, it is ultimately madvise_update_vma() that is invoked, calling vma_modify_flags_name() and vma_modify() in turn. Then, in vma_modify(), we attempt the merge: merged = vma_merge_existing_range(vmg); if (merged) return merged; We invoke this with vmg->start, end set to start, tmp as such: start tmp |<--->| |----------|------| | vma | next | |----------|------| We find ourselves in the merge right scenario, but the one in which we cannot remove the middle (we are offset into vma). Here we have a special case where vmg->start, end get set to perhaps unintuitive values - we intended to shrink the middle VMA and expand the next. This means vmg->start, end are set to... vma->vm_start, start. Now the commit_merge() fails, and vmg->start, end are left like this. This means we return to the rest of vma_modify() with vmg->start, end (here denoted as start', end') set as: start' end' |<-->| |----------|------| | vma | next | |----------|------| So we now erroneously try to split accordingly. This is where the unfortunate ---truncated---

Vendors
-
Not available
Products
-
Metrics (CVSS)
VersionBase scoreBase severityVector
Weaknesses
Attack Patterns
Solution/Workaround
References
HyperlinkResource Type
EPSS History
Score
Latest Score
-
N/A
No data available for selected date range
Percentile
Latest Percentile
-
N/A
No data available for selected date range
Stakeholder-Specific Vulnerability Categorization (SSVC)
▼Common Vulnerabilities and Exposures (CVE)
cve.org
Assigner:Linux
Assigner Org ID:416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published At:01 Apr, 2025 | 15:41
Updated At:11 May, 2026 | 21:09
Rejected At:
▼CVE Numbering Authority (CNA)
mm: abort vma_modify() on merge out of memory failure

In the Linux kernel, the following vulnerability has been resolved: mm: abort vma_modify() on merge out of memory failure The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt. Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values. Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e. the kernel would simply keep retrying reclaim until it succeeded. However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!). Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early. So there is no doubt it is appropriate to simply bail out in this scenario. However, in general we must if at all possible never assume VMG state is stable after a merge attempt, since merge operations update VMG fields. As a result, additionally also make this clear by storing start, end in local variables. The issue was reported originally by syzkaller, and by Brad Spengler (via an off-list discussion), and in both instances it manifested as a triggering of the assert: VM_WARN_ON_VMG(start >= end, vmg); In vma_merge_existing_range(). It seems at least one scenario in which this is occurring is one in which the merge being attempted is due to an madvise() across multiple VMAs which looks like this: start end |<------>| |----------|------| | vma | next | |----------|------| When madvise_walk_vmas() is invoked, we first find vma in the above (determining prev to be equal to vma as we are offset into vma), and then enter the loop. We determine the end of vma that forms part of the range we are madvise()'ing by setting 'tmp' to this value: /* Here vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; We then invoke the madvise() operation via visit(), letting prev get updated to point to vma as part of the operation: /* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Where the visit() function pointer in this instance is madvise_vma_behavior(). As observed in syzkaller reports, it is ultimately madvise_update_vma() that is invoked, calling vma_modify_flags_name() and vma_modify() in turn. Then, in vma_modify(), we attempt the merge: merged = vma_merge_existing_range(vmg); if (merged) return merged; We invoke this with vmg->start, end set to start, tmp as such: start tmp |<--->| |----------|------| | vma | next | |----------|------| We find ourselves in the merge right scenario, but the one in which we cannot remove the middle (we are offset into vma). Here we have a special case where vmg->start, end get set to perhaps unintuitive values - we intended to shrink the middle VMA and expand the next. This means vmg->start, end are set to... vma->vm_start, start. Now the commit_merge() fails, and vmg->start, end are left like this. This means we return to the rest of vma_modify() with vmg->start, end (here denoted as start', end') set as: start' end' |<-->| |----------|------| | vma | next | |----------|------| So we now erroneously try to split accordingly. This is where the unfortunate ---truncated---

Affected Products
Vendor
Linux Kernel Organization, IncLinux
Product
Linux
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Program Files
  • mm/vma.c
Default Status
unaffected
Versions
Affected
  • From 2f1c6611b0a89afcb8641471af5f223c9caa01e0 before 79636d2981b066acd945117387a9533f56411f6f (git)
  • From 2f1c6611b0a89afcb8641471af5f223c9caa01e0 before 53fd215f7886a1e8dea5a9ca1391dbb697fff601 (git)
  • From 2f1c6611b0a89afcb8641471af5f223c9caa01e0 before 47b16d0462a460000b8f05dfb1292377ac48f3ca (git)
Vendor
Linux Kernel Organization, IncLinux
Product
Linux
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Program Files
  • mm/vma.c
Default Status
affected
Versions
Affected
  • 6.12
Unaffected
  • From 0 before 6.12 (semver)
  • From 6.12.19 through 6.12.* (semver)
  • From 6.13.7 through 6.13.* (semver)
  • From 6.14 through * (original_commit_for_fix)
Metrics
VersionBase scoreBase severityVector
Metrics Other Info
Impacts
CAPEC IDDescription
Solutions
Configurations
Workarounds
Exploits
Credits
Timeline
EventDate
Replaced By
Rejected Reason
References
HyperlinkResource
https://git.kernel.org/stable/c/79636d2981b066acd945117387a9533f56411f6f
N/A
https://git.kernel.org/stable/c/53fd215f7886a1e8dea5a9ca1391dbb697fff601
N/A
https://git.kernel.org/stable/c/47b16d0462a460000b8f05dfb1292377ac48f3ca
N/A
Hyperlink: https://git.kernel.org/stable/c/79636d2981b066acd945117387a9533f56411f6f
Resource: N/A
Hyperlink: https://git.kernel.org/stable/c/53fd215f7886a1e8dea5a9ca1391dbb697fff601
Resource: N/A
Hyperlink: https://git.kernel.org/stable/c/47b16d0462a460000b8f05dfb1292377ac48f3ca
Resource: N/A
Information is not available yet
▼National Vulnerability Database (NVD)
nvd.nist.gov
Source:416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published At:01 Apr, 2025 | 16:15
Updated At:30 Oct, 2025 | 19:45

In the Linux kernel, the following vulnerability has been resolved: mm: abort vma_modify() on merge out of memory failure The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt. Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values. Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e. the kernel would simply keep retrying reclaim until it succeeded. However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!). Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early. So there is no doubt it is appropriate to simply bail out in this scenario. However, in general we must if at all possible never assume VMG state is stable after a merge attempt, since merge operations update VMG fields. As a result, additionally also make this clear by storing start, end in local variables. The issue was reported originally by syzkaller, and by Brad Spengler (via an off-list discussion), and in both instances it manifested as a triggering of the assert: VM_WARN_ON_VMG(start >= end, vmg); In vma_merge_existing_range(). It seems at least one scenario in which this is occurring is one in which the merge being attempted is due to an madvise() across multiple VMAs which looks like this: start end |<------>| |----------|------| | vma | next | |----------|------| When madvise_walk_vmas() is invoked, we first find vma in the above (determining prev to be equal to vma as we are offset into vma), and then enter the loop. We determine the end of vma that forms part of the range we are madvise()'ing by setting 'tmp' to this value: /* Here vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; We then invoke the madvise() operation via visit(), letting prev get updated to point to vma as part of the operation: /* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Where the visit() function pointer in this instance is madvise_vma_behavior(). As observed in syzkaller reports, it is ultimately madvise_update_vma() that is invoked, calling vma_modify_flags_name() and vma_modify() in turn. Then, in vma_modify(), we attempt the merge: merged = vma_merge_existing_range(vmg); if (merged) return merged; We invoke this with vmg->start, end set to start, tmp as such: start tmp |<--->| |----------|------| | vma | next | |----------|------| We find ourselves in the merge right scenario, but the one in which we cannot remove the middle (we are offset into vma). Here we have a special case where vmg->start, end get set to perhaps unintuitive values - we intended to shrink the middle VMA and expand the next. This means vmg->start, end are set to... vma->vm_start, start. Now the commit_merge() fails, and vmg->start, end are left like this. This means we return to the rest of vma_modify() with vmg->start, end (here denoted as start', end') set as: start' end' |<-->| |----------|------| | vma | next | |----------|------| So we now erroneously try to split accordingly. This is where the unfortunate ---truncated---

CISA Catalog
Date AddedDue DateVulnerability NameRequired Action
N/A
Date Added: N/A
Due Date: N/A
Vulnerability Name: N/A
Required Action: N/A
Metrics
TypeVersionBase scoreBase severityVector
Primary3.15.5MEDIUM
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Type: Primary
Version: 3.1
Base score: 5.5
Base severity: MEDIUM
Vector:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CPE Matches
Linux Kernel Organization, Inc
linux
>>linux_kernel>>Versions from 6.12(inclusive) to 6.12.19(exclusive)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Linux Kernel Organization, Inc
linux
>>linux_kernel>>Versions from 6.13(inclusive) to 6.13.7(exclusive)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Linux Kernel Organization, Inc
linux
>>linux_kernel>>6.14
cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*
Linux Kernel Organization, Inc
linux
>>linux_kernel>>6.14
cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*
Linux Kernel Organization, Inc
linux
>>linux_kernel>>6.14
cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:*
Linux Kernel Organization, Inc
linux
>>linux_kernel>>6.14
cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:*
Linux Kernel Organization, Inc
linux
>>linux_kernel>>6.14
cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:*
Weaknesses
CWE IDTypeSource
NVD-CWE-noinfoPrimarynvd@nist.gov
CWE ID: NVD-CWE-noinfo
Type: Primary
Source: nvd@nist.gov
Evaluator Description
Evaluator Impact

Evaluator Solution

Vendor Statements
References
HyperlinkSourceResource
https://git.kernel.org/stable/c/47b16d0462a460000b8f05dfb1292377ac48f3ca416baaa9-dc9f-4396-8d5f-8c081fb06d67
Patch
https://git.kernel.org/stable/c/53fd215f7886a1e8dea5a9ca1391dbb697fff601416baaa9-dc9f-4396-8d5f-8c081fb06d67
Patch
https://git.kernel.org/stable/c/79636d2981b066acd945117387a9533f56411f6f416baaa9-dc9f-4396-8d5f-8c081fb06d67
Patch
Hyperlink: https://git.kernel.org/stable/c/47b16d0462a460000b8f05dfb1292377ac48f3ca
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Resource:
Patch
Hyperlink: https://git.kernel.org/stable/c/53fd215f7886a1e8dea5a9ca1391dbb697fff601
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Resource:
Patch
Hyperlink: https://git.kernel.org/stable/c/79636d2981b066acd945117387a9533f56411f6f
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Resource:
Patch

Change History

0
Information is not available yet

Similar CVEs

6890Records found
CVE-2021-47444
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 3.30%
||
7 Day CHG~0.00%
Published-22 May, 2024 | 06:19
Updated-11 May, 2026 | 13:54
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read

In the Linux kernel, the following vulnerability has been resolved: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test") the function connector_bad_edid() started assuming that the memory for the EDID passed to it was big enough to hold `edid[0x7e] + 1` blocks of data (1 extra for the base block). It completely ignored the fact that the function was passed `num_blocks` which indicated how much memory had been allocated for the EDID. Let's fix this by adding a bounds check. This is important for handling the case where there's an error in the first block of the EDID. In that case we will call connector_bad_edid() without having re-allocated memory based on `edid[0x7e]`.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47019
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 7.70%
||
7 Day CHG~0.00%
Published-28 Feb, 2024 | 08:13
Updated-11 May, 2026 | 13:46
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
mt76: mt7921: fix possible invalid register access

In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix possible invalid register access Disable the interrupt and synchronze for the pending irq handlers to ensure the irq tasklet is not being scheduled after the suspend to avoid the possible invalid register access acts when the host pcie controller is suspended. [17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs [17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00 [17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs [17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc [17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs ... 17933.615352] x1 : 00000000000d4200 x0 : ffffff8269ca2300 [17933.620666] Call trace: [17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76] [17933.627234] mt7921_rr+0x38/0x44 [mt7921e] [17933.631339] mt7921_irq_tasklet+0x54/0x1d8 [mt7921e] [17933.636309] tasklet_action_common+0x12c/0x16c [17933.640754] tasklet_action+0x24/0x2c [17933.644418] __do_softirq+0x16c/0x344 [17933.648082] irq_exit+0xa8/0xac [17933.651224] scheduler_ipi+0xd4/0x148 [17933.654890] handle_IPI+0x164/0x2d4 [17933.658379] gic_handle_irq+0x140/0x178 [17933.662216] el1_irq+0xb8/0x180 [17933.665361] cpuidle_enter_state+0xf8/0x204 [17933.669544] cpuidle_enter+0x38/0x4c [17933.673122] do_idle+0x1a4/0x2a8 [17933.676352] cpu_startup_entry+0x24/0x28 [17933.680276] rest_init+0xd4/0xe0 [17933.683508] arch_call_rest_init+0x10/0x18 [17933.687606] start_kernel+0x340/0x3b4 [17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113) [17933.697373] ---[ end trace a24b8e26ffbda3c5 ]--- [17933.767846] Kernel panic - not syncing: Fatal exception in interrupt

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47166
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 2.45%
||
7 Day CHG~0.00%
Published-25 Mar, 2024 | 09:16
Updated-11 May, 2026 | 13:49
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
NFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce()

In the Linux kernel, the following vulnerability has been resolved: NFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce() The value of mirror->pg_bytes_written should only be updated after a successful attempt to flush out the requests on the list.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-787
Out-of-bounds Write
CVE-2021-47563
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 10.02%
||
7 Day CHG~0.00%
Published-24 May, 2024 | 15:12
Updated-11 May, 2026 | 13:57
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ice: avoid bpf_prog refcount underflow

In the Linux kernel, the following vulnerability has been resolved: ice: avoid bpf_prog refcount underflow Ice driver has the routines for managing XDP resources that are shared between ndo_bpf op and VSI rebuild flow. The latter takes place for example when user changes queue count on an interface via ethtool's set_channels(). There is an issue around the bpf_prog refcounting when VSI is being rebuilt - since ice_prepare_xdp_rings() is called with vsi->xdp_prog as an argument that is used later on by ice_vsi_assign_bpf_prog(), same bpf_prog pointers are swapped with each other. Then it is also interpreted as an 'old_prog' which in turn causes us to call bpf_prog_put on it that will decrement its refcount. Below splat can be interpreted in a way that due to zero refcount of a bpf_prog it is wiped out from the system while kernel still tries to refer to it: [ 481.069429] BUG: unable to handle page fault for address: ffffc9000640f038 [ 481.077390] #PF: supervisor read access in kernel mode [ 481.083335] #PF: error_code(0x0000) - not-present page [ 481.089276] PGD 100000067 P4D 100000067 PUD 1001cb067 PMD 106d2b067 PTE 0 [ 481.097141] Oops: 0000 [#1] PREEMPT SMP PTI [ 481.101980] CPU: 12 PID: 3339 Comm: sudo Tainted: G OE 5.15.0-rc5+ #1 [ 481.110840] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [ 481.122021] RIP: 0010:dev_xdp_prog_id+0x25/0x40 [ 481.127265] Code: 80 00 00 00 00 0f 1f 44 00 00 89 f6 48 c1 e6 04 48 01 fe 48 8b 86 98 08 00 00 48 85 c0 74 13 48 8b 50 18 31 c0 48 85 d2 74 07 <48> 8b 42 38 8b 40 20 c3 48 8b 96 90 08 00 00 eb e8 66 2e 0f 1f 84 [ 481.148991] RSP: 0018:ffffc90007b63868 EFLAGS: 00010286 [ 481.155034] RAX: 0000000000000000 RBX: ffff889080824000 RCX: 0000000000000000 [ 481.163278] RDX: ffffc9000640f000 RSI: ffff889080824010 RDI: ffff889080824000 [ 481.171527] RBP: ffff888107af7d00 R08: 0000000000000000 R09: ffff88810db5f6e0 [ 481.179776] R10: 0000000000000000 R11: ffff8890885b9988 R12: ffff88810db5f4bc [ 481.188026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 481.196276] FS: 00007f5466d5bec0(0000) GS:ffff88903fb00000(0000) knlGS:0000000000000000 [ 481.205633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 481.212279] CR2: ffffc9000640f038 CR3: 000000014429c006 CR4: 00000000003706e0 [ 481.220530] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 481.228771] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 481.237029] Call Trace: [ 481.239856] rtnl_fill_ifinfo+0x768/0x12e0 [ 481.244602] rtnl_dump_ifinfo+0x525/0x650 [ 481.249246] ? __alloc_skb+0xa5/0x280 [ 481.253484] netlink_dump+0x168/0x3c0 [ 481.257725] netlink_recvmsg+0x21e/0x3e0 [ 481.262263] ____sys_recvmsg+0x87/0x170 [ 481.266707] ? __might_fault+0x20/0x30 [ 481.271046] ? _copy_from_user+0x66/0xa0 [ 481.275591] ? iovec_from_user+0xf6/0x1c0 [ 481.280226] ___sys_recvmsg+0x82/0x100 [ 481.284566] ? sock_sendmsg+0x5e/0x60 [ 481.288791] ? __sys_sendto+0xee/0x150 [ 481.293129] __sys_recvmsg+0x56/0xa0 [ 481.297267] do_syscall_64+0x3b/0xc0 [ 481.301395] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 481.307238] RIP: 0033:0x7f5466f39617 [ 481.311373] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bd 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2f 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 [ 481.342944] RSP: 002b:00007ffedc7f4308 EFLAGS: 00000246 ORIG_RAX: 000000000000002f [ 481.361783] RAX: ffffffffffffffda RBX: 00007ffedc7f5460 RCX: 00007f5466f39617 [ 481.380278] RDX: 0000000000000000 RSI: 00007ffedc7f5360 RDI: 0000000000000003 [ 481.398500] RBP: 00007ffedc7f53f0 R08: 0000000000000000 R09: 000055d556f04d50 [ 481.416463] R10: 0000000000000077 R11: 0000000000000246 R12: 00007ffedc7f5360 [ 481.434131] R13: 00007ffedc7f5350 R14: 00007ffedc7f5344 R15: 0000000000000e98 [ 481.451520] Modules linked in: ice ---truncated---

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47568
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 9.29%
||
7 Day CHG~0.00%
Published-24 May, 2024 | 15:12
Updated-11 May, 2026 | 13:57
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ksmbd: fix memleak in get_file_stream_info()

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix memleak in get_file_stream_info() Fix memleak in get_file_stream_info()

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2025-21713
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 7.50%
||
7 Day CHG~0.00%
Published-27 Feb, 2025 | 02:07
Updated-11 May, 2026 | 21:04
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
powerpc/pseries/iommu: Don't unset window if it was never set

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: Don't unset window if it was never set On pSeries, when user attempts to use the same vfio container used by different iommu group, the spapr_tce_set_window() returns -EPERM and the subsequent cleanup leads to the below crash. Kernel attempted to read user page (308) - exploit attempt? BUG: Kernel NULL pointer dereference on read at 0x00000308 Faulting instruction address: 0xc0000000001ce358 Oops: Kernel access of bad area, sig: 11 [#1] NIP: c0000000001ce358 LR: c0000000001ce05c CTR: c00000000005add0 <snip> NIP [c0000000001ce358] spapr_tce_unset_window+0x3b8/0x510 LR [c0000000001ce05c] spapr_tce_unset_window+0xbc/0x510 Call Trace: spapr_tce_unset_window+0xbc/0x510 (unreliable) tce_iommu_attach_group+0x24c/0x340 [vfio_iommu_spapr_tce] vfio_container_attach_group+0xec/0x240 [vfio] vfio_group_fops_unl_ioctl+0x548/0xb00 [vfio] sys_ioctl+0x754/0x1580 system_call_exception+0x13c/0x330 system_call_vectored_common+0x15c/0x2ec <snip> --- interrupt: 3000 Fix this by having null check for the tbl passed to the spapr_tce_unset_window().

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-47643
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 10.98%
||
7 Day CHG~0.00%
Published-26 Feb, 2025 | 01:54
Updated-11 May, 2026 | 13:58
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
media: ir_toy: free before error exiting

In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: free before error exiting Fix leak in error path.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47215
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.30%
||
7 Day CHG~0.00%
Published-10 Apr, 2024 | 19:01
Updated-11 May, 2026 | 13:50
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net/mlx5e: kTLS, Fix crash in RX resync flow

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix crash in RX resync flow For the TLS RX resync flow, we maintain a list of TLS contexts that require some attention, to communicate their resync information to the HW. Here we fix list corruptions, by protecting the entries against movements coming from resync_handle_seq_match(), until their resync handling in napi is fully completed.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47258
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 2.70%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 14:19
Updated-11 May, 2026 | 13:51
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
scsi: core: Fix error handling of scsi_host_alloc()

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix error handling of scsi_host_alloc() After device is initialized via device_initialize(), or its name is set via dev_set_name(), the device has to be freed via put_device(). Otherwise device name will be leaked because it is allocated dynamically in dev_set_name(). Fix the leak by replacing kfree() with put_device(). Since scsi_host_dev_release() properly handles IDA and kthread removal, remove special-casing these from the error handling as well.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47522
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.91%
||
7 Day CHG~0.00%
Published-24 May, 2024 | 15:09
Updated-11 May, 2026 | 13:56
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
HID: bigbenff: prevent null pointer dereference

In the Linux kernel, the following vulnerability has been resolved: HID: bigbenff: prevent null pointer dereference When emulating the device through uhid, there is a chance we don't have output reports and so report_field is null.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-46909
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.84%
||
7 Day CHG~0.00%
Published-27 Feb, 2024 | 06:53
Updated-11 May, 2026 | 13:44
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ARM: footbridge: fix PCI interrupt mapping

In the Linux kernel, the following vulnerability has been resolved: ARM: footbridge: fix PCI interrupt mapping Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in pci_device_probe()"), the PCI code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init, this causes an oops if a PCI driver is loaded or bound after the kernel has initialised.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-754
Improper Check for Unusual or Exceptional Conditions
CVE-2021-47090
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.91%
||
7 Day CHG~0.00%
Published-04 Mar, 2024 | 18:10
Updated-11 May, 2026 | 13:47
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()

In the Linux kernel, the following vulnerability has been resolved: mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page() Hulk Robot reported a panic in put_page_testzero() when testing madvise() with MADV_SOFT_OFFLINE. The BUG() is triggered when retrying get_any_page(). This is because we keep MF_COUNT_INCREASED flag in second try but the refcnt is not increased. page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) ------------[ cut here ]------------ kernel BUG at include/linux/mm.h:737! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 5 PID: 2135 Comm: sshd Tainted: G B 5.16.0-rc6-dirty #373 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: release_pages+0x53f/0x840 Call Trace: free_pages_and_swap_cache+0x64/0x80 tlb_flush_mmu+0x6f/0x220 unmap_page_range+0xe6c/0x12c0 unmap_single_vma+0x90/0x170 unmap_vmas+0xc4/0x180 exit_mmap+0xde/0x3a0 mmput+0xa3/0x250 do_exit+0x564/0x1470 do_group_exit+0x3b/0x100 __do_sys_exit_group+0x13/0x20 __x64_sys_exit_group+0x16/0x20 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: ---[ end trace e99579b570fe0649 ]--- RIP: 0010:release_pages+0x53f/0x840

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47020
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.80%
||
7 Day CHG~0.00%
Published-29 Feb, 2024 | 22:31
Updated-11 May, 2026 | 13:46
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
soundwire: stream: fix memory leak in stream config error path

In the Linux kernel, the following vulnerability has been resolved: soundwire: stream: fix memory leak in stream config error path When stream config is failed, master runtime will release all slave runtime in the slave_rt_list, but slave runtime is not added to the list at this time. This patch frees slave runtime in the config error path to fix the memory leak.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2025-23153
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.29% / 52.73%
||
7 Day CHG+0.22%
Published-01 May, 2025 | 12:55
Updated-11 May, 2026 | 21:13
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
arm/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch()

In the Linux kernel, the following vulnerability has been resolved: arm/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch() Fix a silly bug where an array was used outside of its scope.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47610
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 9.40%
||
7 Day CHG~0.00%
Published-19 Jun, 2024 | 14:57
Updated-11 May, 2026 | 13:57
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/msm: Fix null ptr access msm_ioctl_gem_submit()

In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix null ptr access msm_ioctl_gem_submit() Fix the below null pointer dereference in msm_ioctl_gem_submit(): 26545.260705: Call trace: 26545.263223: kref_put+0x1c/0x60 26545.266452: msm_ioctl_gem_submit+0x254/0x744 26545.270937: drm_ioctl_kernel+0xa8/0x124 26545.274976: drm_ioctl+0x21c/0x33c 26545.278478: drm_compat_ioctl+0xdc/0xf0 26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100 26545.287169: el0_svc_common+0xf8/0x250 26545.291025: do_el0_svc_compat+0x28/0x54 26545.295066: el0_svc_compat+0x10/0x1c 26545.298838: el0_sync_compat_handler+0xa8/0xcc 26545.303403: el0_sync_compat+0x188/0x1c0 26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008) 26545.318799: Kernel panic - not syncing: Oops: Fatal exception

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-47018
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 3.40%
||
7 Day CHG~0.00%
Published-28 Feb, 2024 | 08:13
Updated-11 May, 2026 | 13:46
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
powerpc/64: Fix the definition of the fixmap area

In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Fix the definition of the fixmap area At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47649
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 3.03%
||
7 Day CHG~0.00%
Published-26 Feb, 2025 | 01:54
Updated-11 May, 2026 | 13:58
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
udmabuf: validate ubuf->pagecount

In the Linux kernel, the following vulnerability has been resolved: udmabuf: validate ubuf->pagecount Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The problem was in ubuf->pages == ZERO_PTR. ubuf->pagecount is calculated from arguments passed from user-space. If user creates udmabuf with list.size == 0 then ubuf->pagecount will be also equal to zero; it causes kmalloc_array() to return ZERO_PTR. Fix it by validating ubuf->pagecount before passing it to kmalloc_array().

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47024
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.79%
||
7 Day CHG~0.00%
Published-28 Feb, 2024 | 08:13
Updated-23 May, 2026 | 15:19
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
vsock/virtio: free queued packets when closing socket

In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47364
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 3.28%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 15:03
Updated-11 May, 2026 | 13:53
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
comedi: Fix memory leak in compat_insnlist()

In the Linux kernel, the following vulnerability has been resolved: comedi: Fix memory leak in compat_insnlist() `compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST` ioctl (whenwhen `CONFIG_COMPAT` is enabled). It allocates memory to temporarily hold an array of `struct comedi_insn` converted from the 32-bit version in user space. This memory is only being freed if there is a fault while filling the array, otherwise it is leaked. Add a call to `kfree()` to fix the leak.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47127
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.36%
||
7 Day CHG~0.00%
Published-15 Mar, 2024 | 20:14
Updated-11 May, 2026 | 13:48
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ice: track AF_XDP ZC enabled queues in bitmap

In the Linux kernel, the following vulnerability has been resolved: ice: track AF_XDP ZC enabled queues in bitmap Commit c7a219048e45 ("ice: Remove xsk_buff_pool from VSI structure") silently introduced a regression and broke the Tx side of AF_XDP in copy mode. xsk_pool on ice_ring is set only based on the existence of the XDP prog on the VSI which in turn picks ice_clean_tx_irq_zc to be executed. That is not something that should happen for copy mode as it should use the regular data path ice_clean_tx_irq. This results in a following splat when xdpsock is run in txonly or l2fwd scenarios in copy mode: <snip> [ 106.050195] BUG: kernel NULL pointer dereference, address: 0000000000000030 [ 106.057269] #PF: supervisor read access in kernel mode [ 106.062493] #PF: error_code(0x0000) - not-present page [ 106.067709] PGD 0 P4D 0 [ 106.070293] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 106.074721] CPU: 61 PID: 0 Comm: swapper/61 Not tainted 5.12.0-rc2+ #45 [ 106.081436] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 106.092027] RIP: 0010:xp_raw_get_dma+0x36/0x50 [ 106.096551] Code: 74 14 48 b8 ff ff ff ff ff ff 00 00 48 21 f0 48 c1 ee 30 48 01 c6 48 8b 87 90 00 00 00 48 89 f2 81 e6 ff 0f 00 00 48 c1 ea 0c <48> 8b 04 d0 48 83 e0 fe 48 01 f0 c3 66 66 2e 0f 1f 84 00 00 00 00 [ 106.115588] RSP: 0018:ffffc9000d694e50 EFLAGS: 00010206 [ 106.120893] RAX: 0000000000000000 RBX: ffff88984b8c8a00 RCX: ffff889852581800 [ 106.128137] RDX: 0000000000000006 RSI: 0000000000000000 RDI: ffff88984cd8b800 [ 106.135383] RBP: ffff888123b50001 R08: ffff889896800000 R09: 0000000000000800 [ 106.142628] R10: 0000000000000000 R11: ffffffff826060c0 R12: 00000000000000ff [ 106.149872] R13: 0000000000000000 R14: 0000000000000040 R15: ffff888123b50018 [ 106.157117] FS: 0000000000000000(0000) GS:ffff8897e0f40000(0000) knlGS:0000000000000000 [ 106.165332] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 106.171163] CR2: 0000000000000030 CR3: 000000000560a004 CR4: 00000000007706e0 [ 106.178408] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 106.185653] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 106.192898] PKRU: 55555554 [ 106.195653] Call Trace: [ 106.198143] <IRQ> [ 106.200196] ice_clean_tx_irq_zc+0x183/0x2a0 [ice] [ 106.205087] ice_napi_poll+0x3e/0x590 [ice] [ 106.209356] __napi_poll+0x2a/0x160 [ 106.212911] net_rx_action+0xd6/0x200 [ 106.216634] __do_softirq+0xbf/0x29b [ 106.220274] irq_exit_rcu+0x88/0xc0 [ 106.223819] common_interrupt+0x7b/0xa0 [ 106.227719] </IRQ> [ 106.229857] asm_common_interrupt+0x1e/0x40 </snip> Fix this by introducing the bitmap of queues that are zero-copy enabled, where each bit, corresponding to a queue id that xsk pool is being configured on, will be set/cleared within ice_xsk_pool_{en,dis}able and checked within ice_xsk_pool(). The latter is a function used for deciding which napi poll routine is executed. Idea is being taken from our other drivers such as i40e and ixgbe.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-47425
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 6.36%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 15:04
Updated-11 May, 2026 | 13:54
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
i2c: acpi: fix resource leak in reconfiguration device addition

In the Linux kernel, the following vulnerability has been resolved: i2c: acpi: fix resource leak in reconfiguration device addition acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a reference on the adapter which is never released which will result in a reference count leak and render the adapter unremovable. Make sure to put the adapter after creating the client in the same manner that we do for OF. [wsa: fixed title]

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47117
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.67%
||
7 Day CHG~0.00%
Published-15 Mar, 2024 | 20:14
Updated-11 May, 2026 | 13:48
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed

In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed We got follow bug_on when run fsstress with injecting IO fault: [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368] ext4_find_extent+0x300/0x330 [ext4] [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4_readpage+0x54/0x100 [ext4] [130747.337359] generic_file_buffered_read+0x410/0xae8 [130747.337767] generic_file_read_iter+0x114/0x190 [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556] __vfs_read+0x11c/0x188 [130747.338851] vfs_read+0x94/0x150 [130747.339110] ksys_read+0x74/0xf0 This patch's modification is according to Jan Kara's suggestion in: https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/ "I see. Now I understand your patch. Honestly, seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user triggerable). Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as is and don't try to fix it (which also means we will not create overlapping extents)."

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47126
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.79%
||
7 Day CHG~0.00%
Published-15 Mar, 2024 | 20:14
Updated-11 May, 2026 | 13:48
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions

In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions Reported by syzbot: HEAD commit: 90c911ad Merge tag 'fixes' of git://git.kernel.org/pub/scm.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master dashboard link: https://syzkaller.appspot.com/bug?extid=123aa35098fd3c000eb7 compiler: Debian clang version 11.0.1-2 ================================================================== BUG: KASAN: slab-out-of-bounds in fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline] BUG: KASAN: slab-out-of-bounds in fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732 Read of size 8 at addr ffff8880145c78f8 by task syz-executor.4/17760 CPU: 0 PID: 17760 Comm: syz-executor.4 Not tainted 5.12.0-rc8-syzkaller #0 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x202/0x31e lib/dump_stack.c:120 print_address_description+0x5f/0x3b0 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report+0x15c/0x200 mm/kasan/report.c:416 fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline] fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732 fib6_nh_release+0x9a/0x430 net/ipv6/route.c:3536 fib6_info_destroy_rcu+0xcb/0x1c0 net/ipv6/ip6_fib.c:174 rcu_do_batch kernel/rcu/tree.c:2559 [inline] rcu_core+0x8f6/0x1450 kernel/rcu/tree.c:2794 __do_softirq+0x372/0x7a6 kernel/softirq.c:345 invoke_softirq kernel/softirq.c:221 [inline] __irq_exit_rcu+0x22c/0x260 kernel/softirq.c:422 irq_exit_rcu+0x5/0x20 kernel/softirq.c:434 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1100 </IRQ> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632 RIP: 0010:lock_acquire+0x1f6/0x720 kernel/locking/lockdep.c:5515 Code: f6 84 24 a1 00 00 00 02 0f 85 8d 02 00 00 f7 c3 00 02 00 00 49 bd 00 00 00 00 00 fc ff df 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 3d 00 00 00 00 00 4b c7 44 3d 09 00 00 00 00 43 c7 44 3d RSP: 0018:ffffc90009e06560 EFLAGS: 00000206 RAX: 1ffff920013c0cc0 RBX: 0000000000000246 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90009e066e0 R08: dffffc0000000000 R09: fffffbfff1f992b1 R10: fffffbfff1f992b1 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000000 R15: 1ffff920013c0cb4 rcu_lock_acquire+0x2a/0x30 include/linux/rcupdate.h:267 rcu_read_lock include/linux/rcupdate.h:656 [inline] ext4_get_group_info+0xea/0x340 fs/ext4/ext4.h:3231 ext4_mb_prefetch+0x123/0x5d0 fs/ext4/mballoc.c:2212 ext4_mb_regular_allocator+0x8a5/0x28f0 fs/ext4/mballoc.c:2379 ext4_mb_new_blocks+0xc6e/0x24f0 fs/ext4/mballoc.c:4982 ext4_ext_map_blocks+0x2be3/0x7210 fs/ext4/extents.c:4238 ext4_map_blocks+0xab3/0x1cb0 fs/ext4/inode.c:638 ext4_getblk+0x187/0x6c0 fs/ext4/inode.c:848 ext4_bread+0x2a/0x1c0 fs/ext4/inode.c:900 ext4_append+0x1a4/0x360 fs/ext4/namei.c:67 ext4_init_new_dir+0x337/0xa10 fs/ext4/namei.c:2768 ext4_mkdir+0x4b8/0xc00 fs/ext4/namei.c:2814 vfs_mkdir+0x45b/0x640 fs/namei.c:3819 ovl_do_mkdir fs/overlayfs/overlayfs.h:161 [inline] ovl_mkdir_real+0x53/0x1a0 fs/overlayfs/dir.c:146 ovl_create_real+0x280/0x490 fs/overlayfs/dir.c:193 ovl_workdir_create+0x425/0x600 fs/overlayfs/super.c:788 ovl_make_workdir+0xed/0x1140 fs/overlayfs/super.c:1355 ovl_get_workdir fs/overlayfs/super.c:1492 [inline] ovl_fill_super+0x39ee/0x5370 fs/overlayfs/super.c:2035 mount_nodev+0x52/0xe0 fs/super.c:1413 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2903 [inline] path_mount+0x196f/0x2be0 fs/namespace.c:3233 do_mount fs/namespace.c:3246 [inline] __do_sys_mount fs/namespace.c:3454 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3431 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 Code: ff ff c3 66 2e 0f 1f 84 ---truncated---

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-125
Out-of-bounds Read
CVE-2021-47436
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.84%
||
7 Day CHG~0.00%
Published-22 May, 2024 | 06:19
Updated-23 May, 2026 | 15:19
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
usb: musb: dsps: Fix the probe error path

In the Linux kernel, the following vulnerability has been resolved: usb: musb: dsps: Fix the probe error path Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") has inverted the calls to dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without updating correctly the error path. dsps_create_musb_pdev() allocates and registers a new platform device which must be unregistered and freed with platform_device_unregister(), and this is missing upon dsps_setup_optional_vbus_irq() error. While on the master branch it seems not to trigger any issue, I observed a kernel crash because of a NULL pointer dereference with a v5.10.70 stable kernel where the patch mentioned above was backported. With this kernel version, -EPROBE_DEFER is returned the first time dsps_setup_optional_vbus_irq() is called which triggers the probe to error out without unregistering the platform device. Unfortunately, on the Beagle Bone Black Wireless, the platform device still living in the system is being used by the USB Ethernet gadget driver, which during the boot phase triggers the crash. My limited knowledge of the musb world prevents me to revert this commit which was sent to silence a robot warning which, as far as I understand, does not make sense. The goal of this patch was to prevent an IRQ to fire before the platform device being registered. I think this cannot ever happen due to the fact that enabling the interrupts is done by the ->enable() callback of the platform musb device, and this platform device must be already registered in order for the core or any other user to use this callback. Hence, I decided to fix the error path, which might prevent future errors on mainline kernels while also fixing older ones.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-47009
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 8.84%
||
7 Day CHG~0.00%
Published-28 Feb, 2024 | 08:13
Updated-23 May, 2026 | 15:19
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
KEYS: trusted: Fix memory leak on object td

In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak on object td Two error return paths are neglecting to free allocated object td, causing a memory leak. Fix this by returning via the error return path that securely kfree's td. Fixes clang scan-build warning: security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential memory leak [unix.Malloc]

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47584
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.91%
||
7 Day CHG~0.00%
Published-19 Jun, 2024 | 14:53
Updated-11 May, 2026 | 13:57
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
iocost: Fix divide-by-zero on donation from low hweight cgroup

In the Linux kernel, the following vulnerability has been resolved: iocost: Fix divide-by-zero on donation from low hweight cgroup The donation calculation logic assumes that the donor has non-zero after-donation hweight, so the lowest active hweight a donating cgroup can have is 2 so that it can donate 1 while keeping the other 1 for itself. Earlier, we only donated from cgroups with sizable surpluses so this condition was always true. However, with the precise donation algorithm implemented, f1de2439ec43 ("blk-iocost: revamp donation amount determination") made the donation amount calculation exact enabling even low hweight cgroups to donate. This means that in rare occasions, a cgroup with active hweight of 1 can enter donation calculation triggering the following warning and then a divide-by-zero oops. WARNING: CPU: 4 PID: 0 at block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867] ... RIP: 0010:transfer_surpluses.cold+0x0/0x53 Code: 92 ff 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff <0f> 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0 4 ... Call Trace: <IRQ> ioc_timer_fn+0x1043/0x1390 call_timer_fn+0xa1/0x2c0 __run_timers.part.0+0x1ec/0x2e0 run_timer_softirq+0x35/0x70 ... iocg: invalid donation weights in /a/b: active=1 donating=1 after=0 Fix it by excluding cgroups w/ active hweight < 2 from donating. Excluding these extreme low hweight donations shouldn't affect work conservation in any meaningful way.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-369
Divide By Zero
CVE-2021-46997
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 5.31%
||
7 Day CHG~0.00%
Published-28 Feb, 2024 | 08:13
Updated-11 May, 2026 | 13:45
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
arm64: entry: always set GIC_PRIO_PSR_I_SET during entry

In the Linux kernel, the following vulnerability has been resolved: arm64: entry: always set GIC_PRIO_PSR_I_SET during entry Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This matches the gic_prio_kentry_setup that we have to retain for ret_to_user. The original splat from Zenghui's report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Modules linked in: | CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | pc : lockdep_hardirqs_off+0xd4/0xe8 | lr : lockdep_hardirqs_off+0xd4/0xe8 | sp : ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0 | x7 : ffff8000119f0800 x6 : c0000000ffff7fff | x5 : ffff8000119f07a8 x4 : 0000000000000001 | x3 : 9bcdab23f2432800 x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: | lockdep_hardirqs_off+0xd4/0xe8 | enter_from_kernel_mode.isra.5+0x7c/0xa8 | el1_abort+0x24/0x100 | el1_sync_handler+0x80/0xd0 | el1_sync+0x6c/0x100 | __arch_clear_user+0xc/0x90 | load_elf_binary+0x9fc/0x1450 | bprm_execve+0x404/0x880 | kernel_execve+0x180/0x188 | call_usermodehelper_exec_async+0xdc/0x158 | ret_from_fork+0x10/0x18

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2025-23152
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.14% / 34.68%
||
7 Day CHG+0.07%
Published-01 May, 2025 | 12:55
Updated-11 May, 2026 | 21:13
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
arm64/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch()

In the Linux kernel, the following vulnerability has been resolved: arm64/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch() Fix a silly bug where an array was used outside of its scope.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47257
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.84%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 14:19
Updated-11 May, 2026 | 13:51
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net: ieee802154: fix null deref in parse dev addr

In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: fix null deref in parse dev addr Fix a logic error that could result in a null deref if the user sets the mode incorrectly for the given addr type.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-47511
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.80%
||
7 Day CHG~0.00%
Published-24 May, 2024 | 15:09
Updated-11 May, 2026 | 13:56
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ALSA: pcm: oss: Fix negative period/buffer sizes

In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix negative period/buffer sizes The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers. This patch changes the code to handle with ssize_t and adds the proper error checks appropriately.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47141
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 3.40%
||
7 Day CHG~0.00%
Published-25 Mar, 2024 | 09:07
Updated-11 May, 2026 | 13:48
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
gve: Add NULL pointer checks when freeing irqs.

In the Linux kernel, the following vulnerability has been resolved: gve: Add NULL pointer checks when freeing irqs. When freeing notification blocks, we index priv->msix_vectors. If we failed to allocate priv->msix_vectors (see abort_with_msix_vectors) this could lead to a NULL pointer dereference if the driver is unloaded.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2025-23160
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 5.74%
||
7 Day CHG-0.10%
Published-01 May, 2025 | 12:55
Updated-23 May, 2026 | 15:58
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.

Action-Not Available
Vendor-Linux Kernel Organization, IncSiemens AGDebian GNU/Linux
Product-debian_linuxlinux_kernelLinuxSIMATIC CN 4100
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47532
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.65%
||
7 Day CHG~0.00%
Published-24 May, 2024 | 15:09
Updated-11 May, 2026 | 13:56
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/msm/devfreq: Fix OPP refcnt leak

In the Linux kernel, the following vulnerability has been resolved: drm/msm/devfreq: Fix OPP refcnt leak

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47221
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 6.03%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 14:19
Updated-11 May, 2026 | 13:50
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
mm/slub: actually fix freelist pointer vs redzoning

In the Linux kernel, the following vulnerability has been resolved: mm/slub: actually fix freelist pointer vs redzoning It turns out that SLUB redzoning ("slub_debug=Z") checks from s->object_size rather than from s->inuse (which is normally bumped to make room for the freelist pointer), so a cache created with an object size less than 24 would have the freelist pointer written beyond s->object_size, causing the redzone to be corrupted by the freelist pointer. This was very visible with "slub_debug=ZF": BUG test (Tainted: G B ): Right Redzone overwritten ----------------------------------------------------------------------------- INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x0000000000000000 flags=0x8000000000000200 INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620 Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........ Object (____ptrval____): 00 00 00 00 00 f6 f4 a5 ........ Redzone (____ptrval____): 40 1d e8 1a aa @.... Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........ Adjust the offset to stay within s->object_size. (Note that no caches of in this size range are known to exist in the kernel currently.)

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-763
Release of Invalid Pointer or Reference
CVE-2021-47077
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 3.40%
||
7 Day CHG~0.00%
Published-01 Mar, 2024 | 21:15
Updated-11 May, 2026 | 13:47
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
scsi: qedf: Add pointer checks in qedf_update_link_speed()

In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Add pointer checks in qedf_update_link_speed() The following trace was observed: [ 14.042059] Call Trace: [ 14.042061] <IRQ> [ 14.042068] qedf_link_update+0x144/0x1f0 [qedf] [ 14.042117] qed_link_update+0x5c/0x80 [qed] [ 14.042135] qed_mcp_handle_link_change+0x2d2/0x410 [qed] [ 14.042155] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042170] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042186] ? qed_rd+0x13/0x40 [qed] [ 14.042205] qed_mcp_handle_events+0x437/0x690 [qed] [ 14.042221] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042239] qed_int_sp_dpc+0x3a6/0x3e0 [qed] [ 14.042245] tasklet_action_common.isra.14+0x5a/0x100 [ 14.042250] __do_softirq+0xe4/0x2f8 [ 14.042253] irq_exit+0xf7/0x100 [ 14.042255] do_IRQ+0x7f/0xd0 [ 14.042257] common_interrupt+0xf/0xf [ 14.042259] </IRQ> API qedf_link_update() is getting called from QED but by that time shost_data is not initialised. This results in a NULL pointer dereference when we try to dereference shost_data while updating supported_speeds. Add a NULL pointer check before dereferencing shost_data.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-47595
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.98%
||
7 Day CHG~0.00%
Published-19 Jun, 2024 | 14:53
Updated-11 May, 2026 | 13:57
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net/sched: sch_ets: don't remove idle classes from the round-robin list

In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_ets: don't remove idle classes from the round-robin list Shuang reported that the following script: 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bands 8 strict 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a own -b 00:c1:a0:c1:a0:00 -t udp & 3) tc qdisc change dev ddd0 handle 10: ets bands 4 strict 2 quanta 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 crashes systematically when line 2) is commented: list_del corruption, ffff8e028404bd30->next is LIST_POISON1 (dead000000000100) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:47! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 954 Comm: tc Not tainted 5.16.0-rc4+ #478 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 00010246 RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800 R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400 FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 0000000000350ef0 Call Trace: <TASK> ets_qdisc_change+0x58b/0xa70 [sch_ets] tc_modify_qdisc+0x323/0x880 rtnetlink_rcv_msg+0x169/0x4a0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x257/0x4d0 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1f2/0x260 ___sys_sendmsg+0x7c/0xc0 __sys_sendmsg+0x57/0xa0 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7efdc8031338 Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000061b37a97 RCX: 00007efdc8031338 RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940 R10: 000000000000000c R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000 </TASK> Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common joydev pcspkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: sch_ets] ---[ end trace f35878d1912655c2 ]--- RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 00010246 RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800 R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400 FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000 ---truncated---

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47229
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.86%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 14:19
Updated-11 May, 2026 | 13:50
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
PCI: aardvark: Fix kernel panic during PIO transfer

In the Linux kernel, the following vulnerability has been resolved: PCI: aardvark: Fix kernel panic during PIO transfer Trying to start a new PIO transfer by writing value 0 in PIO_START register when previous transfer has not yet completed (which is indicated by value 1 in PIO_START) causes an External Abort on CPU, which results in kernel panic: SError Interrupt on CPU0, code 0xbf000002 -- SError Kernel panic - not syncing: Asynchronous SError Interrupt To prevent kernel panic, it is required to reject a new PIO transfer when previous one has not finished yet. If previous PIO transfer is not finished yet, the kernel may issue a new PIO request only if the previous PIO transfer timed out. In the past the root cause of this issue was incorrectly identified (as it often happens during link retraining or after link down event) and special hack was implemented in Trusted Firmware to catch all SError events in EL3, to ignore errors with code 0xbf000002 and not forwarding any other errors to kernel and instead throw panic from EL3 Trusted Firmware handler. Links to discussion and patches about this issue: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541 But the real cause was the fact that during link retraining or after link down event the PIO transfer may take longer time, up to the 1.44s until it times out. This increased probability that a new PIO transfer would be issued by kernel while previous one has not finished yet. After applying this change into the kernel, it is possible to revert the mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47289
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 3.40%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 14:35
Updated-11 May, 2026 | 13:51
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ACPI: fix NULL pointer dereference

In the Linux kernel, the following vulnerability has been resolved: ACPI: fix NULL pointer dereference Commit 71f642833284 ("ACPI: utils: Fix reference counting in for_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointer that was possibly NULL. That fails miserably, because that helper inline function is not set up to handle that case. Just make acpi_dev_put() silently accept a NULL pointer, rather than calling down to put_device() with an invalid offset off that NULL pointer.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-47617
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 7.80%
||
7 Day CHG~0.00%
Published-20 Jun, 2024 | 10:57
Updated-23 May, 2026 | 15:20
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
PCI: pciehp: Fix infinite loop in IRQ handler upon power fault

In the Linux kernel, the following vulnerability has been resolved: PCI: pciehp: Fix infinite loop in IRQ handler upon power fault The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-835
Loop with Unreachable Exit Condition ('Infinite Loop')
CVE-2021-47246
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.29%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 14:19
Updated-11 May, 2026 | 13:50
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net/mlx5e: Fix page reclaim for dead peer hairpin

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix page reclaim for dead peer hairpin When adding a hairpin flow, a firmware-side send queue is created for the peer net device, which claims some host memory pages for its internal ring buffer. If the peer net device is removed/unbound before the hairpin flow is deleted, then the send queue is not destroyed which leads to a stack trace on pci device remove: [ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource [ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110 [ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0 [ 748.002171] ------------[ cut here ]------------ [ 748.001177] FW pages counter is 4 after reclaiming all pages [ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core] [ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1 [ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9 [ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286 [ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000 [ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51 [ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8 [ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30 [ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000 [ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000 [ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0 [ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 748.001654] Call Trace: [ 748.000576] ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core] [ 748.001416] ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core] [ 748.001354] ? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core] [ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core] [ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core] [ 748.001200] remove_one+0x5f/0xc0 [mlx5_core] [ 748.001075] pci_device_remove+0x9f/0x1d0 [ 748.000833] device_release_driver_internal+0x1e0/0x490 [ 748.001207] unbind_store+0x19f/0x200 [ 748.000942] ? sysfs_file_ops+0x170/0x170 [ 748.001000] kernfs_fop_write_iter+0x2bc/0x450 [ 748.000970] new_sync_write+0x373/0x610 [ 748.001124] ? new_sync_read+0x600/0x600 [ 748.001057] ? lock_acquire+0x4d6/0x700 [ 748.000908] ? lockdep_hardirqs_on_prepare+0x400/0x400 [ 748.001126] ? fd_install+0x1c9/0x4d0 [ 748.000951] vfs_write+0x4d0/0x800 [ 748.000804] ksys_write+0xf9/0x1d0 [ 748.000868] ? __x64_sys_read+0xb0/0xb0 [ 748.000811] ? filp_open+0x50/0x50 [ 748.000919] ? syscall_enter_from_user_mode+0x1d/0x50 [ 748.001223] do_syscall_64+0x3f/0x80 [ 748.000892] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 748.00 ---truncated---

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47273
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 6.10%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 14:20
Updated-11 May, 2026 | 13:51
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled When only PHY1 is used (for example on Odroid-HC4), the regmap init code uses the usb2 ports when doesn't initialize the PHY1 regmap entry. This fixes: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... pc : regmap_update_bits_base+0x40/0xa0 lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 ... Call trace: regmap_update_bits_base+0x40/0xa0 dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 dwc3_meson_g12a_usb2_init+0x7c/0xc8 dwc3_meson_g12a_usb_init+0x28/0x48 dwc3_meson_g12a_probe+0x298/0x540 platform_probe+0x70/0xe0 really_probe+0xf0/0x4d8 driver_probe_device+0xfc/0x168 ...

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-47471
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.05% / 14.92%
||
7 Day CHG~0.00%
Published-22 May, 2024 | 06:23
Updated-11 May, 2026 | 13:55
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm: mxsfb: Fix NULL pointer dereference crash on unload

In the Linux kernel, the following vulnerability has been resolved: drm: mxsfb: Fix NULL pointer dereference crash on unload The mxsfb->crtc.funcs may already be NULL when unloading the driver, in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from mxsfb_unload() leads to NULL pointer dereference. Since all we care about is masking the IRQ and mxsfb->base is still valid, just use that to clear and mask the IRQ.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2020-10781
Matching Score-8
Assigner-Red Hat, Inc.
ShareView Details
Matching Score-8
Assigner-Red Hat, Inc.
CVSS Score-5.5||MEDIUM
EPSS-0.10% / 27.59%
||
7 Day CHG~0.00%
Published-16 Sep, 2020 | 00:00
Updated-04 Aug, 2024 | 11:14
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available

A flaw was found in the Linux Kernel before 5.8-rc6 in the ZRAM kernel module, where a user with a local account and the ability to read the /sys/class/zram-control/hot_add file can create ZRAM device nodes in the /dev/ directory. This read allocates kernel memory and is not accounted for a user that triggers the creation of that ZRAM device. With this vulnerability, continually reading the device may consume a large amount of system memory and cause the Out-of-Memory (OOM) killer to activate and terminate random userspace processes, possibly making the system inoperable.

Action-Not Available
Vendor-Linux KernelLinux Kernel Organization, IncDebian GNU/Linux
Product-debian_linuxlinux_kernelkernel
CWE ID-CWE-732
Incorrect Permission Assignment for Critical Resource
CVE-2021-47421
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.06% / 17.71%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 15:04
Updated-11 May, 2026 | 13:54
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume In current code, when a PCI error state pci_channel_io_normal is detectd, it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI driver will continue the execution of PCI resume callback report_resume by pci_walk_bridge, and the callback will go into amdgpu_pci_resume finally, where write lock is releasd unconditionally without acquiring such lock first. In this case, a deadlock will happen when other threads start to acquire the read lock. To fix this, add a member in amdgpu_device strucutre to cache pci_channel_state, and only continue the execution in amdgpu_pci_resume when it's pci_channel_io_frozen.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2021-47071
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 3.28%
||
7 Day CHG~0.00%
Published-01 Mar, 2024 | 21:15
Updated-11 May, 2026 | 13:47
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
uio_hv_generic: Fix a memory leak in error handling paths

In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix a memory leak in error handling paths If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be updated and 'hv_uio_cleanup()' in the error handling path will not be able to free the corresponding buffer. In such a case, we need to free the buffer explicitly.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47405
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.63%
||
7 Day CHG~0.00%
Published-21 May, 2024 | 15:03
Updated-11 May, 2026 | 13:54
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
HID: usbhid: free raw_report buffers in usbhid_stop

In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: free raw_report buffers in usbhid_stop Free the unsent raw_report buffers when the device is removed. Fixes a memory leak reported by syzbot at: https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47612
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 7.45%
||
7 Day CHG~0.00%
Published-19 Jun, 2024 | 14:58
Updated-11 May, 2026 | 13:57
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
nfc: fix segfault in nfc_genl_dump_devices_done

In the Linux kernel, the following vulnerability has been resolved: nfc: fix segfault in nfc_genl_dump_devices_done When kmalloc in nfc_genl_dump_devices() fails then nfc_genl_dump_devices_done() segfaults as below KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x80 Call Trace: <TASK> class_dev_iter_exit+0x15/0x20 nfc_genl_dump_devices_done+0x3b/0x50 genl_lock_done+0x84/0xd0 netlink_sock_destruct+0x8f/0x270 __sk_destruct+0x64/0x3b0 sk_destruct+0xa8/0xd0 __sk_free+0x2e8/0x3d0 sk_free+0x51/0x90 netlink_sock_destruct_work+0x1c/0x20 process_one_work+0x411/0x710 worker_thread+0x6fd/0xa80

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
CVE-2021-47546
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 3.28%
||
7 Day CHG~0.00%
Published-24 May, 2024 | 15:09
Updated-23 May, 2026 | 15:20
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ipv6: fix memory leak in fib6_rule_suppress

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix memory leak in fib6_rule_suppress The kernel leaks memory when a `fib` rule is present in IPv6 nftables firewall rules and a suppress_prefix rule is present in the IPv6 routing rules (used by certain tools such as wg-quick). In such scenarios, every incoming packet will leak an allocation in `ip6_dst_cache` slab cache. After some hours of `bpftrace`-ing and source code reading, I tracked down the issue to ca7a03c41753 ("ipv6: do not free rt if FIB_LOOKUP_NOREF is set on suppress rule"). The problem with that change is that the generic `args->flags` always have `FIB_LOOKUP_NOREF` set[1][2] but the IPv6-specific flag `RT6_LOOKUP_F_DST_NOREF` might not be, leading to `fib6_rule_suppress` not decreasing the refcount when needed. How to reproduce: - Add the following nftables rule to a prerouting chain: meta nfproto ipv6 fib saddr . mark . iif oif missing drop This can be done with: sudo nft create table inet test sudo nft create chain inet test test_chain '{ type filter hook prerouting priority filter + 10; policy accept; }' sudo nft add rule inet test test_chain meta nfproto ipv6 fib saddr . mark . iif oif missing drop - Run: sudo ip -6 rule add table main suppress_prefixlength 0 - Watch `sudo slabtop -o | grep ip6_dst_cache` to see memory usage increase with every incoming ipv6 packet. This patch exposes the protocol-specific flags to the protocol specific `suppress` function, and check the protocol-specific `flags` argument for RT6_LOOKUP_F_DST_NOREF instead of the generic FIB_LOOKUP_NOREF when decreasing the refcount, like this. [1]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L71 [2]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L99

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-401
Missing Release of Memory after Effective Lifetime
CVE-2021-47502
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.83%
||
7 Day CHG~0.00%
Published-24 May, 2024 | 15:01
Updated-11 May, 2026 | 13:55
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ASoC: codecs: wcd934x: handle channel mappping list correctly

In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd934x: handle channel mappping list correctly Currently each channel is added as list to dai channel list, however there is danger of adding same channel to multiple dai channel list which endups corrupting the other list where its already added. This patch ensures that the channel is actually free before adding to the dai channel list and also ensures that the channel is on the list before deleting it. This check was missing previously, and we did not hit this issue as we were testing very simple usecases with sequence of amixer commands.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CVE-2021-47484
Matching Score-8
Assigner-kernel.org
ShareView Details
Matching Score-8
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 9.32%
||
7 Day CHG~0.00%
Published-22 May, 2024 | 08:19
Updated-11 May, 2026 | 13:55
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
octeontx2-af: Fix possible null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix possible null pointer dereference. This patch fixes possible null pointer dereference in files "rvu_debugfs.c" and "rvu_nix.c"

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-476
NULL Pointer Dereference
  • Previous
  • 1
  • 2
  • 3
  • 4
  • 5
  • ...
  • 137
  • 138
  • Next
Details not found