| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| n8n is an open source workflow automation platform. Prior to 2.37.7 and 2.38.2, the /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members endpoints checked only whether the caller could manage the role type. A caller with role:manageProject could name a project the caller could not list and obtain member names and email addresses. The affected controller is packages/cli/src/controllers/role.controller.ts, which omitted the project:list scope check. This issue is fixed in versions 2.37.7 and 2.38.2. |
| In the Linux kernel, the following vulnerability has been resolved:
NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock
nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with
list_for_each_entry_safe(ni, tmp, ...). For each expired entry it
sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the
source vfsmount, then reacquires the lock to list_del + kfree the
entry and continue iterating via the macro's saved tmp pointer.
The nsui_busy flag protects the current ni from concurrent
nfsd4_ssc_setup_dul() finders during the lock-drop window, but it
does not pin tmp. Another nfsd RPC thread that fails its source-
server mount and reaches nfsd4_ssc_cancel_dul() will, during that
same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount
item, and release the lock. If that item is the saved tmp of the
expire walk, the next iteration dereferences a freed
nfsd4_ssc_umount_item.
Restart the walk from the head after the mntput() unlock window so
no saved next pointer survives the lock-drop. The list is bounded
by the number of active inter-server source mounts (typically small)
and the expire delayed-work runs periodically rather than per-IO,
so the restart is cheap. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix cpntf publish race in nfs4_init_cp_state
nfs4_alloc_init_cpntf_state() published the new cpntf entry into the
s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then
took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap
the entry is reachable by so_id but cp_list is still {NULL,NULL} from
kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as
cnr_stateid, so any NFSv4.2 client can drive it) reaches
manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on
the zeroed list_head, oopsing the server.
Fold the cs_type assignment and the list_add() into the same critical
section as idr_alloc_cyclic(), so a concurrent lookup either misses the
entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after
allocation and switch _free_cpntf_state_locked() to list_del_init() so a
stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and
skips the list_add, preserving NFS4_COPY_STID semantics. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget
The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has
multiple errors that can result in either an out-of-bounds write or
leaking uninitialized kernel memory to the client:
- fh_len doesn't account for XDR padding on the file handle data
- uid and gid lengths use "8 + len" but xdr_encode_opaque() actually
writes "4 + xdr_align_size(len)" bytes
- ds_len omits the flags and stats_collect_hint fields (8 bytes),
while len's header constant overestimates by 8 bytes -- these
partially cancel but leave a net mismatch
The worst case occurs with short strings (e.g. uid=0, gid=0 with an
odd-sized file handle), where the function writes up to 5 bytes past
the reserved XDR buffer. Conversely, when string lengths happen to be
4-byte aligned, the reservation is too large and stale buffer content
is sent to the client.
Fix this by breaking out every encoded field explicitly in the ds_len
calculation, using xdr_align_size() for all variable-length opaque
fields, and correcting the header constants. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: initialize copy-notify stateid before publishing it
nfsd4_copy_notify() finished initializing the cpntf state after
nfs4_alloc_init_cpntf_state() had already linked it into the
s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the
membership reference) and none held for the caller. A racing
OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable
so_id) could reach manage_cpntf_state() and free the entry, turning the
caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid
writes into use-after-free. The owning clientid was also only recorded
after publication, so it could not gate an ownership check in that window.
Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state()
before nfs4_init_cp_state() publishes the entry, and return it with an
extra reference. The caller reads the stateid under that reference and
drops it with nfs4_put_cpntf_state(); on a late error the laundromat
reaps the entry. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: revoke copy-notify stateids before dropping their reference
Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent
stid's sc_cp_list, pinned by a single membership reference.
_free_cpntf_state_locked() only unlinks an entry once its refcount reaches
zero, so any revoke path that runs while a concurrent
find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops
the reference without unlinking, leaving the entry discoverable with its
membership reference already consumed. A second revoke or a laundromat tick
then frees it while the reader still holds the pointer -- a
KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state().
This affected all three revoke paths:
- The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called
_free_cpntf_state_locked() on the first list entry; a holder that had
bumped cs_count made it return early, so the next iteration
re-decremented and burned the holder's reference.
- OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise
used _free_cpntf_state_locked() and could drop 2->1 without unlinking.
Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and
sc_cp_list first (deferring the final free to any holder), and use it from
all three revoke paths. The drain now walks with list_for_each_entry_safe()
and revokes each entry unconditionally, so it terminates in one pass per
entry regardless of cs_count. The unhash is gated on
!list_empty(&cps->cp_list); the idr_remove() gate matters because
idr_alloc_cyclic() may have recycled the so_id by then. Keep
_free_cpntf_state_locked() for the reference-holder put path only, where a
concurrent revoke may already have unlinked the entry (its list_del_init()
then a no-op). |
| In the Linux kernel, the following vulnerability has been resolved:
HID: picolcd: clamp eeprom debugfs read to bytes actually received
picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte
supplied by the device in its REPORT_EE_DATA reply -- clamped only to
the caller's read() count:
ret = resp->raw_data[2];
if (ret > s)
ret = s;
if (copy_to_user(u, resp->raw_data+3, ret))
It never checks resp->raw_size, the number of bytes picolcd_raw_event()
actually copied into the 64-byte raw_data[] of the kmalloc'd struct
picolcd_pending. A device (or a spoofed picoLCD) returning a length byte
of 0xff, read with a count >= 255, makes copy_to_user() read past
raw_data[] into adjacent slab memory and return it to userspace through
the debugfs "eeprom" file:
BUG: KASAN: slab-out-of-bounds in _copy_to_user
Read of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd]
The debug-dump path in the same file already validates the device length
byte against the received size before trusting it; this read does not.
The file is created S_IRUSR (root-only) and a crafted device is needed,
so it is neither unprivileged- nor remotely-triggerable.
Clamp the copy length to resp->raw_size - 3 (the payload actually
received, minus the 3-byte header), floored at 0 for short replies. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: mcp2221: stop device IO before hid_hw_stop
Quiesce device IO at the start of the devm cleanup callback
mcp2221_hid_unregister() so that incoming HID reports cannot race with
hardware teardown during probe failure or device removal, addressing a
potential use-after-free.
Guard the call to hid_device_io_stop() with io_started. On normal
removal hid_device_remove() has already cleared io_started before the
devres group is released, so an unconditional call would otherwise hit
the !io_started path and emit a spurious "io already stopped" warning
on every removal. The guard preserves the probe-failure balancing,
where io_started is still set after hid_device_io_start(), while
staying silent on the normal removal path. |
| In the Linux kernel, the following vulnerability has been resolved:
eventfs: Initialize ei->children and ei->list in init_ei()
eventfs_create_dir() allocates the eventfs_inode and initializes it with
init_ei(). But this does not initialize the eventfs_inode list_heads. If
the eventfs_create_dir() fails due to memory pressure, it will call
free_ei() before it initialized the lists, and that checks to make sure
the eventfs_inode has no children. But because the list wasn't
initialized, it will give a false warning.
Fix it by moving the list initialization into init_ei().
[ Rewrote change log ] |
| In the Linux kernel, the following vulnerability has been resolved:
ecryptfs: hold msg ctx list lock when cleaning daemon queue
ecryptfs_exorcise_daemon() drops queued messages from a dying daemon
without holding ecryptfs_msg_ctx_lists_mux, but
ecryptfs_msg_ctx_alloc_to_free() requires that lock.
Take the list lock while moving the queued contexts back to the free
list to avoid racing with other global msg ctx list users. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: ssd1307fb: defer I2C transfers from damage callbacks
The fbdev damage callbacks may run from fbcon while printk has disabled
preemption. They currently update the display synchronously, which enters
the sleeping I2C transfer path from atomic context.
A complete report from an RK3566 system follows:
[ 258.129004] watchdog: watchdog0: watchdog did not stop!
[ 258.129067] BUG: scheduling while atomic: systemd/1/0x00000003
[ 258.129076] Modules linked in: algif_hash algif_skcipher af_alg bnep
binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart
fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card
motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1
ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb
brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm
snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine
v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2
spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem
videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2
stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio
stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables
x_tables autofs4
[ 258.129215] Preemption disabled at:
[ 258.129216] [<ffff80008012f96c>] vprintk_emit+0x11c/0x340
[ 258.129234] CPU: 0 PID: 1 Comm: systemd Tainted: G C
6.6.0-rc5-rockchip-rk356x #4
[ 258.129239] Hardware name: Rockchip RK3566 OPi 3B (DT)
[ 258.129243] Call trace:
[ 258.129245] dump_backtrace+0xa0/0x128
[ 258.129252] show_stack+0x20/0x38
[ 258.129256] dump_stack_lvl+0x60/0xb0
[ 258.129265] dump_stack+0x18/0x28
[ 258.129269] __schedule_bug+0xa0/0xc8
[ 258.129274] __schedule+0x9ac/0xd30
[ 258.129279] schedule+0x60/0x100
[ 258.129282] schedule_timeout+0x194/0x338
[ 258.129289] rk3x_i2c_xfer_common.isra.0+0x384/0x498
[ 258.129296] rk3x_i2c_xfer+0x20/0x60
[ 258.129300] __i2c_transfer+0x194/0x648
[ 258.129308] i2c_transfer+0x9c/0x130
[ 258.129313] i2c_transfer_buffer_flags+0x64/0x98
[ 258.129318] ssd1307fb_update_rect+0x42c/0x560 [ssd1307fb]
[ 258.129334] ssd1307fb_defio_imageblit+0x34/0x50 [ssd1307fb]
[ 258.129343] soft_cursor+0x13c/0x210
[ 258.129350] bit_cursor+0x2dc/0x550
[ 258.129354] fbcon_cursor+0xec/0x108
[ 258.129359] hide_cursor+0x44/0xc8
[ 258.129365] vt_console_print+0x398/0x3b0
[ 258.129370] console_flush_all.isra.0+0x17c/0x410
[ 258.129377] console_unlock+0x4c/0x100
[ 258.129382] vprintk_emit+0x1c8/0x340
[ 258.129386] vprintk_default+0x40/0x58
[ 258.129389] vprintk+0xb8/0xd0
[ 258.129392] _printk+0x68/0x98
[ 258.129398] watchdog_release+0x170/0x230
[ 258.129404] __fput+0xbc/0x288
[ 258.129409] __fput_sync+0x58/0x70
[ 258.129413] __arm64_sys_close+0x40/0x90
[ 258.129419] invoke_syscall+0x4c/0x118
[ 258.129426] el0_svc_common.constprop.0+0x48/0xf0
[ 258.129432] do_el0_svc+0x24/0x38
[ 258.129437] el0_svc+0x48/0x100
[ 258.129443] el0t_64_sync_handler+0xc0/0xc8
[ 258.129448] el0t_64_sync+0x190/0x198
[ 258.573087] ------------[ cut here ]------------
[ 258.573098] DEBUG_LOCKS_WARN_ON(val > preempt_count())
[ 258.573111] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:5871
preempt_count_sub+0x9c/0x148
[ 258.573130] Modules linked in: algif_hash algif_skcipher af_alg bnep
binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart
fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card
motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1
ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb
brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm
snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine
v4l2_vp
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
auxdisplay: charlcd: cancel backlight work on registration failure
With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before
charlcd_register() calls misc_register(). If registration fails, the
caller frees the charlcd object while delayed work still contains its
address.
Add charlcd_deinit() to cancel the delayed work and turn the backlight
off. Use it for both registration rollback and normal unregistration. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()
During fuzz testing, the following issue was discovered:
BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310
__dma_map_sg_attrs+0x217/0x310
dma_map_sg_attrs+0x4a/0x70
ata_qc_issue+0x9f8/0x1420
__ata_scsi_queuecmd+0x1657/0x1740
ata_scsi_queuecmd+0x79a/0x920
scsi_queue_rq+0x4472/0x4f40
blk_mq_dispatch_rq_list+0x1cca/0x3ee0
__blk_mq_sched_dispatch_requests+0x458/0x630
blk_mq_sched_dispatch_requests+0x15b/0x340
__blk_mq_run_hw_queue+0xe5/0x250
__blk_mq_delay_run_hw_queue+0x138/0x780
blk_mq_run_hw_queue+0x4bb/0x7e0
blk_mq_sched_insert_request+0x2a7/0x4c0
blk_execute_rq+0x497/0x8a0
sg_io+0xbe0/0xe20
scsi_ioctl+0x2b36/0x3c60
sr_block_ioctl+0x319/0x440
blkdev_ioctl+0x80f/0xd70
__se_sys_ioctl+0x219/0x420
__x64_sys_ioctl+0x93/0xe0
x64_sys_call+0x1d6c/0x3ad0
do_syscall_64+0x4c/0xa0
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Uninit was created at:
__alloc_pages+0x5c0/0xc80
alloc_pages+0xe0e/0x1050
blk_rq_map_user_iov+0x2b77/0x6100
blk_rq_map_user_io+0x2fa/0x4d0
sg_io+0xad6/0xe20
scsi_ioctl+0x2b36/0x3c60
sr_block_ioctl+0x319/0x440
blkdev_ioctl+0x80f/0xd70
__se_sys_ioctl+0x219/0x420
__x64_sys_ioctl+0x93/0xe0
x64_sys_call+0x1d6c/0x3ad0
do_syscall_64+0x4c/0xa0
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Bytes 14-15 of 16 are uninitialized
Memory access of size 16 starts at ffff88800cbdb000
When processing the last unaligned element of the scatterlist, it is
supplemented with missing bytes in the amount of pad_len. These bytes
remain uninitialized, which leads to a problem.
Extend last_sg->length by pad_len first, then use sg_zero_buffer() to
zero those pad_len bytes. sg_zero_buffer() uses sg_miter internally,
which correctly handles sg entries spanning multiple pages and padding
that crosses a page boundary.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
| In the Linux kernel, the following vulnerability has been resolved:
regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer
In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a
reference on np, which is then assigned to pdev->dev.of_node. The
function immediately calls of_node_put(np), releasing the reference and
leaving pdev->dev.of_node as a dangling pointer.
Remove the of_node_put(np) call to let the device hold the reference. |
| In the Linux kernel, the following vulnerability has been resolved:
openrisc: fix arbitrary kernel memory access via or1k_atomic syscall
sys_or1k_atomic() (syscall 244 in the "or1k" ABI) takes two user
pointers, v1 and v2, and swaps the words they point to in hand-written
assembly.
l.lwz r29,0(r4)
l.lwz r27,0(r5)
l.sw 0(r4),r27
l.sw 0(r5),r29
The pointers are not checked with access_ok(). The four memory
accesses also have no exception table entries.
A caller passes a kernel address as either pointer, and the syscall
reads from and writes to it directly.
This gives an unprivileged process a kernel read/write primitive. It
overwrites kernel data such as the sys_call_table, gaining code
execution in kernel context.
Check both pointers before entering the critical section. Add fixups
for the four memory accesses so faults on valid but unmapped user
addresses return -EFAULT.
[shorne@gmail.com: fix comment style] |
| In the Linux kernel, the following vulnerability has been resolved:
lockd: pin next file across nlm_inspect_file lock-drop
nlm_traverse_files() pins the current file with f_count++ across
a mutex_unlock for nlm_inspect_file(), but nothing pins the saved
next pointer. A concurrent nlm_release_file() can kfree the next
file during the unlock window, and the iterator dereferences freed
memory on the next loop step.
Pin both current and next before the lock-drop. Advance by
swapping the pinned cursors at the end of each iteration so next
is always held alive across the unlock.
Always call nlm_file_release() after dropping the iteration pin,
regardless of whether the file matched the predicate. Use
nlm_file_inuse(), which does a live walk of the inode lock list,
rather than the cached f_locks field, so skipped files that never
ran nlm_inspect_file() are evaluated correctly.
Because every file in a hash bucket is now pinned and released,
files skipped by the is_failover_file predicate that have no
locks, blocks, shares, or external references are deleted during
traversal. The old code never evaluated skipped files for
cleanup. The new behavior is intentional: such files are stale
and should not persist in the table. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq24257: fix use-after-free on remove
The STAT-pin interrupt is devm-managed, so it stays armed until the devm
cleanup that runs after remove() returns. remove() cancels
bq->iilimit_setup_work while the threaded handler can still fire; that
handler reschedules the work and dereferences bq, so the work runs
against freed memory once devm frees bq.
Make the delayed work device-managed with devm_delayed_work_autocancel(),
registered before the interrupt request. The devm cleanup then releases
the interrupt first, so the handler can no longer reschedule the work,
and cancels the work before bq is freed. The explicit
cancel_delayed_work_sync() in remove() is no longer needed and is dropped.
Found by static analysis. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq256xx: drain usb_work before freeing the charger
The USB-PHY notifier queues usb_work, whose handler calls
power_supply_changed(bq->charger). The reset devm action only unregisters
the notifier and was registered before the power supplies, so devm frees
bq->charger on unwind before the action runs; a usb_work still queued can
then dereference it.
Register the reset action after the power supplies, so it unregisters
the notifiers and drains usb_work before the supplies are released.
Initialize usb_work and obtain the PHY references before registering
the notifiers, so the worker cannot run before the supplies exist.
Found by static analysis. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: lp8727: fix use-after-free in lp8727_release_irq()
lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms
pchg->work via schedule_delayed_work(). lp8727_release_irq() currently
cancels the work before freeing the IRQ, so an IRQ delivered in between
can re-arm the work through the threaded handler. After .remove returns
the devm layer frees pchg while lp8727_delayed_func() may still run and
dereference it.
Free the IRQ first so the threaded handler is quiesced and can no longer
queue work, then cancel the delayed work to drain the final generation.
This issue was found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: rt9455: quiesce delayed work before teardown
The threaded IRQ handler can queue pwr_rdy_work,
max_charging_time_work and batt_presence_work. pwr_rdy_work and
batt_presence_work can also queue max_charging_time_work, while
batt_presence_work can requeue itself.
rt9455_remove() cancels max_charging_time_work before
batt_presence_work. The latter can therefore queue
max_charging_time_work after it has already been cancelled:
rt9455_remove() workqueue
cancel pwr_rdy_work
cancel max_charging_time_work
batt_presence_work queues
max_charging_time_work
cancel batt_presence_work
return
devres frees rt9455_info
max_charging_time_work dereferences
rt9455_info
The IRQ also remains registered until devres cleanup and can queue more
work after any of the cancellation calls. If rt9455_hw_init() fails
after the IRQ has been requested, probe returns without cancelling work
that may already have been queued. A pending callback can then access
rt9455_info after it has been freed.
Register rt9455_cancel_all_delayed_works() through
devm_add_action_or_reset() right after devm_power_supply_register().
devres invokes the action in reverse registration order, after the
managed IRQ has been freed and before rt9455_info is released, so the
delayed works are drained in both rt9455_remove() and the probe error
path. Cancel pwr_rdy_work and batt_presence_work before
max_charging_time_work because both can queue the latter.
This issue was found by an in-house static analysis tool. |
