| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| smol-toml is a small, fast, and correct TOML parser and serializer. Prior to 1.7.1, parse() can enter an infinite loop when a value inside an array or inline table is followed by a comment with no trailing newline. In src/util.ts, skipUntil() calls indexOfNewline(), receives -1 at the end of input, and resets the cursor to the beginning of the string instead of leaving the structure scan. The parser then hangs indefinitely and can consume a service's processing capacity when an application parses attacker-controlled TOML. This issue is fixed in version 1.7.1. |
| IBM App Connect Enterprise 13.0.1.0 through 13.0.8.1, and 12.0.1.0 through 12.0.12.28 and IBM Integration Bus for z/OS 10.1.0.0 through 10.1.0.7 could allow a remote attacker to cause a denial of service due to an infinite loop. |
| When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0. |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.16.1, an attacker can craft a PDF that causes pypdf/_doc_common.py _get_outline to consume long runtimes and large amounts of memory when retrieving document outlines with large numbers of entries or deeply nested reused paths because the traversal lacked global entry-count and nesting-depth limits. This issue is fixed in version 6.16.1. |
| @fastify/busboy is a multipart form-data parser. In versions 3.1.0 through 3.2.0, a remote unauthenticated attacker can stall the Node.js event loop by sending a multipart request whose boundary is crafted to a specific length. The vendored streaming search stores its skip table in a fixed 256 entry byte array, and a boundary of exactly 252 bytes makes the search needle 256 bytes, which truncates the default skip distance to zero and turns the search into a CPU bound loop on a small body. A single small request can keep one core busy and deny service to other requests handled by the same process. The issue is fixed in @fastify/busboy 3.2.1, which widens the skip table so the skip distance is preserved. Users should upgrade to 3.2.1. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: serial: digi_acceleport: fix hard lockup on disconnect
If submitting the OOB write urb fails persistently (e.g if the device is
being disconnected) the driver would loop indefinitely with interrupts
disabled.
Check for urb submission errors when sending OOB commands to avoid
hanging if, for example, open(), set_termios() or close() races with a
physical disconnect.
This is issue was flagged by Sashiko when reviewing an unrelated change
to the driver. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: fix VM_BUG_ON_FOLIO() issue in netfs_write_begin() call
The multiple runs of generic/013 test-case is capable
to reproduce a kernel BUG at mm/filemap.c:1504 with
probability of 30%.
while true; do
sudo ./check generic/013
done
[ 9849.452376] page: refcount:3 mapcount:0 mapping:00000000e58ff252 index:0x10781 pfn:0x1c322
[ 9849.452412] memcg:ffff8881a1915800
[ 9849.452417] aops:ceph_aops ino:1000058db9e dentry name(?):"f9XXXXXX"
[ 9849.452432] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
[ 9849.452441] raw: 0017ffffc0000000 0000000000000000 dead000000000122 ffff88816110d248
[ 9849.452445] raw: 0000000000010781 0000000000000000 00000003ffffffff ffff8881a1915800
[ 9849.452447] page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))
[ 9849.452474] ------------[ cut here ]------------
[ 9849.452476] kernel BUG at mm/filemap.c:1504!
[ 9849.478635] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
[ 9849.481772] CPU: 2 UID: 0 PID: 84223 Comm: fsstress Not tainted 7.0.0-rc1+ #18 PREEMPT(full)
[ 9849.482881] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/1
0/2025
[ 9849.484539] RIP: 0010:folio_unlock+0x85/0xa0
[ 9849.485076] Code: 89 df 31 f6 e8 1c f3 ff ff 48 8b 5d f8 c9 31 c0 31 d2 31 f6 31 ff c3 cc
cc cc cc 48 c7 c6 80 6c d9 a7 48 89 df e8 4b b3 10 00 <0f> 0b 48 89 df e8 21 e6 2c 00 eb 9d 0f 1f 40 00 66 66 2e 0f 1f 84
[ 9849.493818] RSP: 0018:ffff8881bb8076b0 EFLAGS: 00010246
[ 9849.495740] RAX: 0000000000000000 RBX: ffffea00070c8980 RCX: 0000000000000000
[ 9849.498678] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 9849.500559] RBP: ffff8881bb8076b8 R08: 0000000000000000 R09: 0000000000000000
[ 9849.501097] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000010782000
[ 9849.502108] R13: ffff8881935de738 R14: ffff88816110d010 R15: 0000000000001000
[ 9849.502516] FS: 00007e36cbe94740(0000) GS:ffff88824a899000(0000) knlGS:0000000000000000
[ 9849.502996] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9849.503810] CR2: 000000c0002b0000 CR3: 000000011bbf6004 CR4: 0000000000772ef0
[ 9849.504459] PKRU: 55555554
[ 9849.504626] Call Trace:
[ 9849.505242] <TASK>
[ 9849.505379] netfs_write_begin+0x7c8/0x10a0
[ 9849.505877] ? __kasan_check_read+0x11/0x20
[ 9849.506384] ? __pfx_netfs_write_begin+0x10/0x10
[ 9849.507178] ceph_write_begin+0x8c/0x1c0
[ 9849.507934] generic_perform_write+0x391/0x8f0
[ 9849.508503] ? __pfx_generic_perform_write+0x10/0x10
[ 9849.509062] ? file_update_time_flags+0x19a/0x4b0
[ 9849.509581] ? ceph_get_caps+0x63/0xf0
[ 9849.510259] ? ceph_get_caps+0x63/0xf0
[ 9849.510530] ceph_write_iter+0xe79/0x1ae0
[ 9849.511282] ? __pfx_ceph_write_iter+0x10/0x10
[ 9849.511839] ? lock_acquire+0x1ad/0x310
[ 9849.512334] ? ksys_write+0xf9/0x230
[ 9849.512582] ? lock_is_held_type+0xaa/0x140
[ 9849.513128] vfs_write+0x512/0x1110
[ 9849.513634] ? __fget_files+0x33/0x350
[ 9849.513893] ? __pfx_vfs_write+0x10/0x10
[ 9849.514143] ? mutex_lock_nested+0x1b/0x30
[ 9849.514394] ksys_write+0xf9/0x230
[ 9849.514621] ? __pfx_ksys_write+0x10/0x10
[ 9849.514887] ? do_syscall_64+0x25e/0x1520
[ 9849.515122] ? __kasan_check_read+0x11/0x20
[ 9849.515366] ? trace_hardirqs_on_prepare+0x178/0x1c0
[ 9849.515655] __x64_sys_write+0x72/0xd0
[ 9849.515885] ? trace_hardirqs_on+0x24/0x1c0
[ 9849.516130] x64_sys_call+0x22f/0x2390
[ 9849.516341] do_syscall_64+0x12b/0x1520
[ 9849.516545] ? do_syscall_64+0x27c/0x1520
[ 9849.516783] ? do_syscall_64+0x27c/0x1520
[ 9849.517003] ? lock_release+0x318/0x480
[ 9849.517220] ? __x64_sys_io_getevents+0x143/0x2d0
[ 9849.517479] ? percpu_ref_put_many.constprop.0+0x8f/0x210
[ 9849.517779] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 9849.518073] ? do_syscall_64+0x25e/0x1520
[ 9849.518291] ? __kasan_check_read+0x11/0x20
[ 9849.518519] ? trace_hardirqs_on_prepare+0x178/0x1c0
[ 9849.518799] ? do_syscall_64+0x27c/0x1520
[ 9
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix potential deadlock in write-through mode
Fix netfs_advance_writethrough() to always unlock the supplied folio and to
mark it dirty if it isn't yet written to the end. Unfortunately, it can't
be marked for writeback until the folio is done with as that may cause a
deadlock against mmapped reads and writes.
Even though it has been marked dirty, premature writeback can't occur as
the caller is holding both inode->i_rwsem (which will prevent concurrent
truncation, fallocation, DIO and other writes) and ictx->wb_lock (which
will cause flushing to wait and writeback to skip or wait).
Note that this may be easier to deal with once the queuing of folios is
split from the generation of subrequests. |
| An attacker who can publish to a queue consumed by an application that has enabled message decompression can crash the consumer JVM with a single ~1 MB message.
Spring AMQP 4.1.0
Spring AMQP 4.0.0 - 4.0.4
Spring AMQP 3.2.0 - 3.2.12
Spring AMQP 2.4.18 and earlier |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.16.0, an attacker can craft a PDF whose cyclic tree structure causes pypdf/generic/_data_structures.py TreeObject.insert_child to follow /Next links indefinitely when a writing code path inserts a child, producing an infinite loop. This issue is fixed in version 6.16.0. |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.16.1, an attacker can craft a PDF that causes pypdf/_page.py PageObject._extract_text and PageObject.extract_xform_text to traverse a directed acyclic graph of reused form XObjects in which each form invokes a child multiple times, creating exponentially many traversal paths and causing long runtimes and large memory consumption. This issue is fixed in version 6.16.1. |
| In Reactor Core, applications that use the Flux.bufferTimeout operator with fairBackpressure enabled are vulnerable to a Denial of Service (DoS) condition.
Reactor Core 3.8.0 - 3.8.6
Reactor Core 3.7.19 and earlier |
| js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 until 3.15.2 and 4.3.2, maxTotalMergeKeys in lib/js-yaml/loader.js and lib/loader.js does not count empty mapping sources while processing the merge key <<. An attacker can alias a large sequence of empty mappings into many merge targets, causing O(N * K) processing while totalMergeKeys remains unchanged and the configured resource limit is never reached. A relatively small YAML document can therefore cause prolonged CPU consumption in applications that parse untrusted YAML, and merge processing is enabled by default on these release lines. This issue is fixed in versions 3.15.2 and 4.3.2. |
| A flaw was found in libssh. A remote authenticated peer can advertise a zero maximum packet size in SSH_MSG_CHANNEL_OPEN, causing later channel writes to loop indefinitely and consume CPU, leading to denial of service. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: wlcore: enable the right set of ciphers
The firmware version number check for IGTK introduced in
commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key")
lets the amount of ciphers decrease on every boot of a too old firmware and
that is practically happening. It also does not take into account other
chips than the wl18xx. On some wl128x, the following can be observed
when connecting via nm to a common ap:
[ 484.113311] wlcore: WARNING could not set keys
[ 484.117828] wlcore: ERROR Could not add or replace key
[ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5)
[ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142
[ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1
[ 484.145721] wlcore: down
[ 484.148986] ieee80211 phy0: Hardware restart was requested
[ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142)
[ 484.633758] wlcore: Association completed.
[ 484.690490] wlcore: ERROR command execute failure 14
[ 484.690490] ------------[ cut here ]------------
[ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892
This repeats endlessly.
Always disable IGTK on wl12xx and fix the decrementing mess. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: vub300: defer reset until cmd_mutex is unlocked
vub300_cmndwork_thread() holds cmd_mutex while it sends a command and
waits for the command response. If the response wait times out,
__vub300_command_response() kills the command URBs and then synchronously
resets the USB device through usb_reset_device().
That reset path re-enters the driver through vub300_pre_reset(), which
also takes cmd_mutex. The worker therefore tries to acquire the same
mutex recursively while it is still holding it from the command path.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the real worker and timeout/reset carrier:
vub300_cmndwork_thread()
__vub300_command_response()
usb_lock_device_for_reset()
usb_reset_device()
vub300_pre_reset()
Lockdep reported the same-task recursive acquisition on cmd_mutex:
WARNING: possible recursive locking detected
... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv]
... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv]
Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv]
*** DEADLOCK ***
Return a flag from __vub300_command_response() when the timeout path needs
a device reset, then perform the reset after vub300_cmndwork_thread() has
cleared the in-flight command state and dropped cmd_mutex. The reset is
still attempted before mmc_request_done(), preserving the existing request
completion ordering while avoiding the recursive lock. |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: (occ) unregister sysfs devices outside occ lock
occ_active(false) and occ_shutdown() unregister sysfs-backed devices while
occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() can
wait for active sysfs callbacks to drain, and those callbacks can enter the
OCC update path and try to take occ->lock again. That gives the unregister
paths the lock ordering occ->lock -> sysfs callback drain, while a callback
has the opposite edge sysfs callback -> occ->lock.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the real unregister and callback carrier:
occ_shutdown()
hwmon_device_unregister()
occ_show_temp_1()
occ_update_response()
Lockdep reported the circular dependency with occ_shutdown() already
holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs
side:
WARNING: possible circular locking dependency detected
... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv]
... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv]
occ_update_response.isra.0+0xb/0x20 [vuln_msv]
occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv]
*** DEADLOCK ***
Serialize hwmon registration and removal with a separate hwmon_lock.
Under that lock, detach occ->hwmon and update occ->active while occ->lock
is held so concurrent OCC state changes still see a stable state, then
drop occ->lock before calling hwmon_device_unregister(). Remove the
driver sysfs group before taking occ->lock in occ_shutdown(), so draining
the driver attributes cannot wait while the OCC mutex is held. Also make
OCC update callbacks return -ENODEV after deactivation, so callbacks that
already passed sysfs active protection do not poll the hardware after
teardown has detached the hwmon device. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: sco: Fix a race condition in sco_sock_timeout()
sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket
is closing while the timer is running, it holds the same lock
(lock_sock(sk)) twice, leading to a deadlock.
CPU 0 CPU 1
==================== ======================
sco_sock_close()
sco_sock_timeout()
lock_sock(sk) // <-- LOCK
__sco_sock_close()
sco_chan_del()
sco_conn_put()
sco_conn_free()
disable_delayed_work_sync()
lock(sk) // <-- SAME LOCK
Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk),
ensuring that no lock_sock(sk) is held before sco_sock_timeout().
Lockdep splat:
WARNING: possible circular locking dependency detected
6.13.0-rc4 #7 Not tainted
syz-executor292/9514 is trying to acquire lock:
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
but task is already holding lock:
ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622
lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158
process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310
worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391
kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389
ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244
-> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}:
check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline]
check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline]
validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904
__lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226
lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline]
start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline]
__flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
__cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline]
disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514
sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline]
kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline]
sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107
sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236
sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526
sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/blueto
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
igc: remove napi_synchronize() in igc_down()
When an AF_XDP zero-copy application is killed abruptly, the XSK pool is
torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the
full budget on every poll, so napi_complete_done() never clears
NAPI_STATE_SCHED.
igc_down() calls napi_synchronize() before napi_disable(), so it spins
forever waiting for that bit and the interface never goes down. Drop the
napi_synchronize() and let napi_disable() do the job -- it sets
NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it
ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after
polling has stopped, matching the recent igb fix b1e067240379. |
| In the Linux kernel, the following vulnerability has been resolved:
iomap: add a separate bio_set for iomap_split_ioend
iomap_split_ioend can split bios that already come from
iomap_ioend_bioset and thus deadlock when the bioset is exhausted.
Add a separate bio_set to avoid this deadlock.
Christian Brauner <brauner@kernel.org> says:
Mark iomap_ioend_split_bioset static as it is only used in ioend.c,
fixing the sparse warning reported by the kernel test robot. |
