| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| L-SMASH through 2.14.5 contains an infinite loop vulnerability in vc1_importer_probe() in importer/vc1_imp.c that allows attackers to hang applications via crafted input files. Attackers can supply a file consisting only of zero bytes, which lsmash_read_file() probes automatically, causing indefinite CPU consumption and denial of service. |
| MP4Parser does not adequately validate MP4 box sizes. A malformed box can cause parsing to make no forward progress and repeatedly process the same input. |
| Frame poisoning in the Layout component. This vulnerability was fixed in Firefox 158, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: avoid livelock while updating retransmit path
sctp_assoc_update_retran_path() can loop forever when every remaining
transport, including retran_path, is SCTP_UNCONFIRMED: the state check
runs before the wraparound test, so the loop cannot observe that it has
completed a full pass.
Fix this by considering a transport only when it is not UNCONFIRMED,
then checking whether the walk has returned to retran_path. This makes
the full-pass termination independent of the transport state while
preserving the existing fallback selection semantics.
Also restore the NULL guard around the retran_path assignment. In the
all-UNCONFIRMED case there is no eligible replacement transport, and
installing NULL would leave later retransmit-path users and the debug
print with a NULL path. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_hfsc: bound the classify inner-filter walk with a drift budget
hfsc_classify() applies the "filter may only point downwards" level check
only when the filter result carries no bound class. A filter created with
a flowid gets res.class set once at bind time, so the check never runs for
it during classification. hfsc_adjust_levels() can later raise a class's
level without revalidating existing bindings, leaving two binds that were
each legal at bind time pointing at each other; the classify walk then
bounces between two interior classes forever with the qdisc lock held and
BH disabled — a soft lockup from a single packet. The stuck walk trips
the watchdog:
watchdog: BUG: soft lockup - CPU#3 stuck for 13s! [ping:444]
RIP: 0010:u32_classify+0x542/0x17f0
...
tcf_classify+0x66/0xa0
hfsc_enqueue+0x166/0xdf0
Bound the traversal with a budget of non-descending hops, the only way a
configured walk can move without descending the class tree once levels
drift after bind time. The budget is cumulative over the whole walk and
is deliberately not reset on a descending hop: a chain that alternates a
descent with a lateral hop would return the budget every lap and never
trip. Descending hops never decrement it, so legitimately deep trees are
unaffected and a terminating lateral chain still classifies normally.
Drop the packet with a rate-limited warning once the budget is exhausted,
mirroring the merged HTB fix.
This is a follow-up to commit 729c4896ab82 ("net/sched: sch_htb: limit
htb_classify inner-class filter hops"), which bounded the same classify
loop on the HTB side but left the HFSC walk unbounded.
Conditions to recreate the bug:
- CONFIG_NET_SCHED, CONFIG_NET_SCH_HFSC, CONFIG_NET_CLS_U32,
CONFIG_LOCKUP_DETECTOR.
- Build a cycle with two legal-at-bind-time flowid binds and a level
drift: class X 1:1 (child of root) with leaf child 1:10; class Y 1:2
(sibling of X) with children 1:20 and 1:200; root u32 filter flowid
1:1; filter on X flowid 1:2 (legal when Y is a leaf); after Y's level
rises to 2, filter on Y flowid 1:1 (legal then). Send one packet (ping
on the device). Unfixed kernel: classify spins with the qdisc lock
held; with softlockup_panic=1 it panics.
- Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915: fix incorrect RCU teardown order
i915_gem_busy_ioctl uses dma_resv_for_each_fence_unlocked() to iterate
over the fences in an GEM object without holding a reference but only
the RCU read side lock.
What can happen here is that the GEM object is destroyed concurrently
while i915_gem_busy_ioctl is still running. This won't free the GEM
objects memory, but still drops all the dma_fence references.
Now when dma_resv_for_each_fence_unlocked() sees a destroyed dma_fence it
assumes that a new fence list was installed and re-starts the loop.
But in the case of a destroyed GEM object a new fence list is never
installed, only the old one freed and therefore the iteration never
finishes resulting in an endless loop.
The solution is to drop the fence references only after the RCU grace
period.
The fixes tag is not necessary the patch introducing the problem, but the
one making it so worse that we need to address it.
This problem was pointed out by Sashiko-bot.
(cherry picked from commit 5113479556025093bf8133bb2dcaa33be2d50921) |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: drop dquot flush lock when we can't find a buffer to flush
LOLLM noticed that xfs_qm_flush_one fails to drop the dquot flush lock
if it can't grab the buffer associated with the dquot. Since there's no
buffer, nobody else is going to drop the dqflock, so we need to do it
ourselves. |
| FreeRDP from 2.3.0 before 3.32.0 contains an infinite loop vulnerability in http_chuncked_read that allows malicious RD Gateways to hang clients by sending incomplete chunked responses. Attackers can send a partial chunk-size line or footer followed by a clean TLS shutdown, causing zero-byte reads to loop forever and freeze the client decoder thread. |
| Omnispace Agora Project before 26.10.0 contains an authentication bypass vulnerability that allows attackers possessing a user's stored bcrypt password hash to authenticate as that user without knowing the actual password, caused by the legacy AGORAP_LOG/AGORAP_PASS cookie mechanism treating the stored hash as a directly replayable bearer credential. Attackers can set the AGORAP_LOG/AGORAP_PASS cookies with a stolen password hash to impersonate any user, including administrators, and gain unauthorized access to the application. |
| Integer overflow in the message buffer growth logic (mbuf_make_room) in PgBouncer 1.21.0 through 1.26.0 allows a remote attacker to cause a denial of service when max_packet_size is configured above 2147483648. A packet header declaring a length above 2^31 makes the buffer size computation overflow, leaving the growth loop unable to terminate. Because PgBouncer serves all clients from a single process, this saturates a CPU core and stalls every pooled connection until the process is restarted. Since 1.23.0 the overflow is reachable before authentication with a five-byte packet header. |
| An infinite loop in PgBouncer 1.20.0 through 1.26.0 allows an unauthenticated remote attacker to cause a denial of service. A StartupMessage whose options parameter contains an empty parameter name, such as "-c=", makes the ignore_startup_parameters list lookup loop forever. Because PgBouncer serves all clients from a single process, this saturates a CPU core and makes PgBouncer unresponsive to all clients until the process is restarted. |
| A Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a remote network attacker to cause a denial of service via EVPN multihoming with preference-based designated-forwarder election. |
| A Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in netsctp.ko of Juniper Networks Junos OS on MX Series allows an unauthenticated network attacker to cause a denial of service via crafted SCTP network traffic. |
| Deadlock in ASP.NET Core allows an unauthorized attacker to deny service over a network. |
| Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.31, 21.2.23, and 22.1.6, the @angular/platform-server DOM emulation parser can enter an infinite synchronous loop when Angular server-side rendering processes attacker-controlled HTML containing an incomplete DOCTYPE that ends with whitespace at end of input. In Domino lib/HTMLParser.js, after_doctype_name_state emits doctype and EOF tokens without advancing nextchar or leaving the fixed-lookahead state, so the scanner repeatedly handles the same EOF marker. A remote unauthenticated attacker can use this condition through server-side HTML parsing paths such as innerHTML binding to consume a Node.js SSR worker at full CPU, starve the event loop, and stop concurrent and subsequent requests. This issue is fixed in versions 20.3.31, 21.2.23, and 22.1.6. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Move cp cleanup out of not operational
The fsm_notoper() routine is called when the device has been
lost, and is (by definition) no longer operational. Since this
can happen asynchronously from the normal behavior of the
driver, the cleanup may happen when holding other locks
in the calling sequence (notably, the cio subchannel lock).
Push the cleanup of the private->cp resources to a workqueue,
where it can be done out from under that lock sequence and
a future patch can safely manage the locking requirements. |
| In the Linux kernel, the following vulnerability has been resolved:
eth: bnxt: avoid deadlock when canceling IRQ affinity notifier
Unregistering IRQ affinity notifiers waits for the callback synchronously.
bnxt takes the netdev instance lock in the notifier (to restart the queue)
and cancels the work under the same lock. This may obviously deadlock.
Move the restart to the async service task. The queue restart isn't
super time sensitive. Store the new TPH tag, schedule the task.
Safely canceling the service task is already ironed out.
In bnxt_request_irq() the order of registering notifier, affinity and
initial TPH programming has to be inverted. I think it was racy
previously since user may trigger an update as soon as notifier
is installed.
There's a small known gap - if pcie_tph_get_cpu_st() fails at init
and the target tag is 0 we may miss programming the entry.
This does not seem worth fixing, the code has skip-on-failure
all over the place, anyway. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack: defer invalid log until after unlock
TCP and SCTP conntrack paths can emit invalid-packet logs while ct->lock
is still held.
When invalid logging is routed to nfnetlink_log and conntrack export is
enabled, the log path can re-enter conntrack netlink glue and dump the
same conntrack again. Protocol attribute dumping may take ct->lock, so
logging while holding that lock can deadlock.
Defer the TCP invalid logs by storing only the minimal log context while
ct->lock is held and emitting the log after unlocking. Also make the TCP
timeout-lowering invalid path return whether a log is needed, then emit
that log after unlocking.
Do the same for the SCTP invalid state-transition log that can be reached
while ct->lock is held.
Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers
that log invalid conntracks while holding ct->lock are caught outside TCP
and SCTP as well. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open()
The failed_dev_add and failed_dev_name paths drop the file-device
reference while wq->wq_lock is still held. If put_device(fdev) drops the
last reference, idxd_file_dev_release() runs synchronously and tries to
take wq->wq_lock again, deadlocking.
Those paths also fall through into the later ctx cleanup labels even
though idxd_file_dev_release() owns that cleanup and frees ctx. This can
make idxd_xa_pasid_remove(ctx) and kfree(ctx) operate on a freed context.
Move idxd_wq_get() before file-device setup can fail, since the release
callback always calls idxd_wq_put(). Then unlock wq->wq_lock before
put_device(fdev) and return directly from the file-device setup failure
path, leaving ctx cleanup to the release callback. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: fix deadlock between metadata writeback and transaction commit
When writing out metadata extent buffers in a zoned filesystem,
btree_writepages() holds fs_info->zoned_meta_io_lock across the whole
writeback loop, including the call to btrfs_check_meta_write_pointer() ->
check_bg_is_active().
For the tree-log block group, check_bg_is_active() may fail to activate
the zone and fall back to btrfs_zone_finish_one_bg() to free an active
zone. That path waits for the running transaction to commit while still
holding zoned_meta_io_lock, but the committer needs that same lock to
write out the tree extents, so the two tasks deadlock:
Task A (kworker, metadata writeback) Task B (fsstress, transaction commit)
------------------------------------ -------------------------------------
wb_workfn() btrfs_commit_transaction(T)
btree_writepages() btrfs_write_and_wait_transaction()
btrfs_zoned_meta_io_lock() btrfs_write_marked_extents()
btrfs_check_meta_write_pointer() btree_writepages()
check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock()
btrfs_zone_finish_one_bg() <blocks on zoned_meta_io_lock,
btrfs_zone_finish() held by Task A>
do_zone_finish()
btrfs_inc_block_group_ro()
btrfs_wait_for_commit()
<blocks waiting for commit
of transaction T, done by
Task B>
The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock
around do_zone_finish() for this exact reason. Do the same in the tree-log
branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire
it afterwards. The lock only protects fs_info->active_{meta,system}_bg,
which this branch does not touch, and ctx->zoned_bg keeps a reference to
the block group across the unlock, so nothing is lost while the lock
is dropped.
This hang occasionally reproduces with fstests generic/475 on a zoned
btrfs filesystem. |
