| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (pfe) of Juniper Networks Junos OS on MX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).When processing a high rate of specific GRE traffic destined to the device, the respective PFE will hang causing traffic forwarding to stop.
When this issue occurs the following logs can be observed:
<fpc #> MQSS(0): LI-3: Received a parcel with more than 512B accompanying data
CHASSISD_FPC_ASIC_ERROR: ASIC Error detected <...>
This issue affects Junos OS:
* all versions before 21.2R3-S9,
* 21.4 versions before 21.4R3-S8,
* 22.2 versions before 22.2R3-S4,
* 22.4 versions before 22.4R3-S5,
* 23.2 versions before 23.2R2-S2,
* 23.4 versions before 23.4R2. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the Routing Protocol Daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a local, low-privileged attacker to cause a Denial-of-Service (DoS).
When a specific "show bgp neighbor" CLI command is run, the rpd cpu utilization rises and eventually causes a crash and restart. Repeated use of this command will cause a sustained DoS condition.
The device is only affected if BGP RIB sharding and update-threading is enabled.
This issue affects Junos OS:
* All versions before 21.2R3-S9,
* from 21.4 before 21.4R3-S8,
* from 22.2 before 22.2R3-S6,
* from 22.4 before 22.4R3-S2,
* from 23.2 before 23.2R2-S3,
* from 23.4 before 23.4R2.
and Junos OS Evolved:
* All versions before 21.2R3-S9-EVO,
* from 21.4-EVO before 21.4R3-S8-EVO,
* from 22.2-EVO before 22.2R3-S6-EVO,
* from 22.4-EVO before 22.4R3-S2-EVO,
* from 23.2-EVO before 23.2R2-S3-EVO,
* from 23.4-EVO before 23.4R2-EVO. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the the IKE daemon (iked) of Juniper Networks Junos OS on SRX Series, MX Series with SPC3 and NFX350 allows allows an unauthenticated, network-based attacker sending specific mismatching parameters as part of the IPsec negotiation to trigger an iked crash leading to Denial of Service (DoS).
This issue is applicable to all platforms that run iked. This issue affects Junos OS on SRX Series, MX Series with SPC3 and NFX350:
* All versions before 21.2R3-S8,
* from 21.4 before 21.4R3-S7,
* from 22.1 before 22.1R3-S2,
* from 22.2 before 22.2R3-S1,
* from 22.3 before 22.3R2-S1, 22.3R3,
* from 22.4 before 22.4R1-S2, 22.4R2, 22.4R3. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS Evolved on PTX Series allows an unauthenticated, network-based attacker to cause impact to confidentiality and availability.
When an output firewall filter is configured with one or more terms where the action is 'reject', packets matching these terms are erroneously sent to the Routing Engine (RE) and further processed there. Processing of these packets will consume limited RE resources. Also responses from the RE back to the source of this traffic could reveal confidential information about the affected device.
This issue only applies to firewall filters applied to WAN or revenue interfaces, so not the mgmt or lo0 interface of the routing-engine, nor any input filters.
This issue affects Junos OS Evolved on PTX Series:
* all versions before 22.4R3-EVO,
* 23.2 versions before 23.2R2-EVO. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on SRX Series and NFX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).
If an affected device receives specific valid traffic destined to the device, it will cause the PFE to crash and restart. Continued receipt and processing of this traffic will create a sustained DoS condition.
This issue affects Junos OS on SRX Series:
* 21.4 versions before 21.4R3-S7.9,
* 22.1 versions before 22.1R3-S5.3,
* 22.2 versions before 22.2R3-S4.11,
* 22.3 versions before 22.3R3,
* 22.4 versions before 22.4R3.
This issue affects Junos OS on NFX Series:
* 21.4 versions before 21.4R3-S8,
* 22.1 versions after 22.1R1,
* 22.2 versions before 22.2R3-S5,
* 22.3 versions before 22.3R3,
* 22.4 versions before 22.4R3.
Junos OS versions prior to 21.4R1 are not affected by this issue. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS Evolved on ACX 7000 Series allows an unauthenticated, adjacent attacker to cause a Denial-of-Service (DoS).
When a device has a Layer 3 or an IRB interface configured in a VPLS instance and specific traffic is received, the evo-pfemand processes crashes which causes a service outage for the respective FPC until the system is recovered manually.
This issue only affects Junos OS Evolved 22.4R2-S1 and 22.4R2-S2 releases and is fixed in 22.4R3. No other releases are affected. |
| In the Linux kernel, the following vulnerability has been resolved:
tee: optee: Fix kernel panic caused by incorrect error handling
The error path while failing to register devices on the TEE bus has a
bug leading to kernel panic as follows:
[ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c
[ 15.406913] Mem abort info:
[ 15.409722] ESR = 0x0000000096000005
[ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits
[ 15.418814] SET = 0, FnV = 0
[ 15.421878] EA = 0, S1PTW = 0
[ 15.425031] FSC = 0x05: level 1 translation fault
[ 15.429922] Data abort info:
[ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000
[ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000
[ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration")
lead to the introduction of this bug. So fix it appropriately. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in OpenSMTPD allows local users to crash OpenSMTPD.
This issue affects openSUSE Tumbleweed: from ? before 7.8.0p0-1.1. |
| An improper check or handling of exceptional conditions vulnerability [CWE-703] in FortiOS version 7.4.0 through 7.4.3 and before 7.2.7, FortiProxy version 7.4.0 through 7.4.3 and before 7.2.9, FortiPAM before 1.2.0 and FortiSwitchManager version 7.2.0 through 7.2.3 and version 7.0.0 through 7.0.3 fgfm daemon may allow an unauthenticated attacker to repeatedly reset the fgfm connection via crafted SSL encrypted TCP requests. |
| iccDEV provides a set of libraries and tools that allow for the interaction, manipulation, and application of International Color Consortium (ICC) color management profiles. Versions prior to 2.3.1.2 have a Type Confusion vulnerability in `CIccSegmentedCurveXml::ToXml()` at `IccXML/IccLibXML/IccMpeXml.cpp`. This vulnerability affects users of the iccDEV library who process ICC color profiles. Version 2.3.1.2 contains a patch. No known workarounds are available. |
| iccDEV provides a set of libraries and tools that allow for the interaction, manipulation, and application of International Color Consortium (ICC) color management profiles. Versions prior to 2.3.1.2 have a Type Confusion vulnerability in `CIccProfileXml::ParseBasic()` at `IccXML/IccLibXML/IccProfileXml.cpp`. This vulnerability affects users of the iccDEV library who process ICC color profiles. Version 2.3.1.2 contains a patch. No known workarounds are available. |
| Improper Check for Unusual or Exceptional Conditions vulnerability in ABB WebPro SNMP Card PowerValue, ABB WebPro SNMP Card PowerValue UL.This issue affects WebPro SNMP Card PowerValue: through 1.1.8.K; WebPro SNMP Card PowerValue UL: through 1.1.8.K. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not BUG_ON() when freeing tree block after error
When freeing a tree block, at btrfs_free_tree_block(), if we fail to
create a delayed reference we don't deal with the error and just do a
BUG_ON(). The error most likely to happen is -ENOMEM, and we have a
comment mentioning that only -ENOMEM can happen, but that is not true,
because in case qgroups are enabled any error returned from
btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned
from btrfs_search_slot() for example) can be propagated back to
btrfs_free_tree_block().
So stop doing a BUG_ON() and return the error to the callers and make
them abort the transaction to prevent leaking space. Syzbot was
triggering this, likely due to memory allocation failure injection. |
| In the Linux kernel, the following vulnerability has been resolved:
MIPS: Octeon: Add PCIe link status check
The standard PCIe configuration read-write interface is used to
access the configuration space of the peripheral PCIe devices
of the mips processor after the PCIe link surprise down, it can
generate kernel panic caused by "Data bus error". So it is
necessary to add PCIe link status check for system protection.
When the PCIe link is down or in training, assigning a value
of 0 to the configuration address can prevent read-write behavior
to the configuration space of peripheral PCIe devices, thereby
preventing kernel panic. |
| A flaw was found in GNUPlot. A segmentation fault via IO_str_init_static_internal may jeopardize the environment. |
| CHOCO TEI WATCHER mini (IB-MCT001) contains an issue with improper check for unusual or exceptional conditions. When the Video Download feature is in a specific communication state, the product's resources may be consumed abnormally. |
| CHOCO TEI WATCHER mini (IB-MCT001) contains an issue with improper check for unusual or exceptional conditions. If a remote attacker sends a specially crafted request to the Video Download interface, the system may become unresponsive. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()
The function core_scsi3_decode_spec_i_port(), in its error code path,
unconditionally calls core_scsi3_lunacl_undepend_item() passing the
dest_se_deve pointer, which may be NULL.
This can lead to a NULL pointer dereference if dest_se_deve remains
unset.
SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg
Unable to handle kernel paging request at virtual address dfff800000000012
Call trace:
core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P)
core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod]
core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod]
target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]
Fix this by adding a NULL check before calling
core_scsi3_lunacl_undepend_item() |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not WARN_ON() if we have PageError set
Whenever we do any extent buffer operations we call
assert_eb_page_uptodate() to complain loudly if we're operating on an
non-uptodate page. Our overnight tests caught this warning earlier this
week
WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50
CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: btrfs-cache btrfs_work_helper
RIP: 0010:assert_eb_page_uptodate+0x3f/0x50
RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246
RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000
RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0
RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000
R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1
R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000
FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0
Call Trace:
extent_buffer_test_bit+0x3f/0x70
free_space_test_bit+0xa6/0xc0
load_free_space_tree+0x1f6/0x470
caching_thread+0x454/0x630
? rcu_read_lock_sched_held+0x12/0x60
? rcu_read_lock_sched_held+0x12/0x60
? rcu_read_lock_sched_held+0x12/0x60
? lock_release+0x1f0/0x2d0
btrfs_work_helper+0xf2/0x3e0
? lock_release+0x1f0/0x2d0
? finish_task_switch.isra.0+0xf9/0x3a0
process_one_work+0x26d/0x580
? process_one_work+0x580/0x580
worker_thread+0x55/0x3b0
? process_one_work+0x580/0x580
kthread+0xf0/0x120
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
This was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer
uptodate when we fail to write it"), however all that fix did was keep
us from finding extent buffers after a failed writeout. It didn't keep
us from continuing to use a buffer that we already had found.
In this case we're searching the commit root to cache the block group,
so we can start committing the transaction and switch the commit root
and then start writing. After the switch we can look up an extent
buffer that hasn't been written yet and start processing that block
group. Then we fail to write that block out and clear Uptodate on the
page, and then we start spewing these errors.
Normally we're protected by the tree lock to a certain degree here. If
we read a block we have that block read locked, and we block the writer
from locking the block before we submit it for the write. However this
isn't necessarily fool proof because the read could happen before we do
the submit_bio and after we locked and unlocked the extent buffer.
Also in this particular case we have path->skip_locking set, so that
won't save us here. We'll simply get a block that was valid when we
read it, but became invalid while we were using it.
What we really want is to catch the case where we've "read" a block but
it's not marked Uptodate. On read we ClearPageError(), so if we're
!Uptodate and !Error we know we didn't do the right thing for reading
the page.
Fix this by checking !Uptodate && !Error, this way we will not complain
if our buffer gets invalidated while we're using it, and we'll maintain
the spirit of the check which is to make sure we have a fully in-cache
block while we're messing with it. |
