| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the Juniper DHCP service (jdhcpd) of Juniper Networks Junos OS and Junos OS Evolved allows a DHCP client in one subnet to exhaust the address pools of other subnets, leading to a Denial of Service (DoS) on the downstream DHCP server.
By default, the DHCP relay agent inserts its own Option 82 information when forwarding client requests, optionally replacing any Option 82 information provided by the client. When a specific DHCP DISCOVER is received in 'forward-only' mode with Option 82, the device should drop the message unless 'trust-option82' is configured. Instead, the DHCP relay forwards these packets to the DHCP server unmodified, which uses up addresses in the DHCP server's address pool, ultimately leading to address pool exhaustion.
This issue affects Junos OS:
* all versions before 21.2R3-S10,
* from 21.4 before 21.4R3-S12,
* all versions of 22.2,
* from 22.4 before 22.4R3-S8,
* from 23.2 before 23.2R2-S5,
* from 23.4 before 23.4R2-S6,
* from 24.2 before 24.2R2-S2,
* from 24.4 before 24.4R2,
* from 25.2 before 25.2R1-S1, 25.2R2.
Junos OS Evolved:
* all versions before 21.4R3-S12-EVO,
* all versions of 22.2-EVO,
* from 22.4 before 22.4R3-S8-EVO,
* from 23.2 before 23.2R2-S5-EVO,
* from 23.4 before 23.4R2-S6-EVO,
* from 24.2 before 24.2R2-S2-EVO,
* from 24.4 before 24.4R2-EVO,
* from 25.2 before 25.2R1-S1-EVO, 25.2R2-EVO. |
| A vulnerability in Palo Alto Networks PAN-OS software enables an unauthenticated attacker to cause a denial of service (DoS) to the firewall. Repeated attempts to trigger this issue results in the firewall entering into maintenance mode. |
| 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 an unauthenticated, network-based attacker to cause an availability impact for downstream devices.
When an affected device receives a specific optional, transitive BGP attribute over an existing BGP session, it will be erroneously modified before propagation to peers. When the attribute is detected as malformed by the peers, these peers will most likely terminate the BGP sessions with the affected devices and thereby cause an availability impact due to the resulting routing churn.
This issue affects:
Junos OS:
* all versions before 22.4R3-S8,
* 23.2 versions before 23.2R2-S5
* 23.4 versions before 23.4R2-S6,
* 24.2 versions before 24.2R2-S2,
* 24.4 versions before 24.4R2;
Junos OS Evolved:
* all versions before 22.4R3-S8-EVO,
* 23.2 versions before 23.2R2-S5-EVO,
* 23.4 versions before 23.4R2-S6-EVO,
* 24.2 versions before 24.2R2-S2-EVO,
* 24.4 versions before 24.4R2-EVO. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the packet forwarding engine (PFE) of Juniper Networks Junos OS on EX4k Series and QFX5k Series platforms allows an unauthenticated network-adjacent attacker flapping an interface to cause traffic between VXLAN Network Identifiers (VNIs) to drop, leading to a Denial of Service (DoS).
On all EX4k and QFX5k platforms, a link flap in an
EVPN-VXLAN configuration Link Aggregation Group (LAG)
results in Inter-VNI traffic dropping when there are multiple load-balanced next-hop routes for the same destination.
This issue is only applicable to systems that support EVPN-VXLAN Virtual Port-Link Aggregation Groups (VPLAG), such as the QFX5110, QFX5120, QFX5200, EX4100, EX4300, EX4400, and EX4650.
Service can only be restored by restarting the affected FPC via the 'request chassis fpc restart slot <slot-number>' command.
This issue affects Junos OS
on EX4k and QFX5k Series:
* all versions before 21.4R3-S12,
* all versions of 22.2
* from 22.4 before 22.4R3-S8,
* from 23.2 before 23.2R2-S5,
* from 23.4 before 23.4R2-S5,
* from 24.2 before 24.2R2-S3,
* from 24.4 before 24.4R2. |
| 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. |
| In Modem, there is a possible system crash due to incorrect error handling. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01311265; Issue ID: MSV-4655. |
| 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. |
| A mishandled security check when creating a WebSocket in a WebWorker caused the Content Security Policy connect-src header to be ignored. This could lead to connections to restricted origins from inside WebWorkers. This vulnerability affects Firefox < 109, Firefox ESR < 102.7, and Thunderbird < 102.7. |
| When checking if the Browsing Context had been discarded in `HttpBaseChannel`, if the load group was not available then it was assumed to have already been discarded which was not always the case for private channels after the private session had ended. This vulnerability affects Firefox < 117, Firefox ESR < 115.2, and Thunderbird < 115.2. |
