🚨 CVE-2025-40605
A Path Traversal vulnerability has been identified in the Email Security appliance allows an attacker to manipulate file system paths by injecting crafted directory-traversal sequences (such as ../) and may access files and directories outside the intended restricted path.
🎖@cveNotify
A Path Traversal vulnerability has been identified in the Email Security appliance allows an attacker to manipulate file system paths by injecting crafted directory-traversal sequences (such as ../) and may access files and directories outside the intended restricted path.
🎖@cveNotify
🚨 CVE-2025-60794
Session tokens and passwords in couch-auth 0.21.2 are stored in JavaScript objects and remain in memory without explicit clearing in src/user.ts lines 700-707. This creates a window of opportunity for sensitive data extraction through memory dumps, debugging tools, or other memory access techniques, potentially leading to session hijacking.
🎖@cveNotify
Session tokens and passwords in couch-auth 0.21.2 are stored in JavaScript objects and remain in memory without explicit clearing in src/user.ts lines 700-707. This creates a window of opportunity for sensitive data extraction through memory dumps, debugging tools, or other memory access techniques, potentially leading to session hijacking.
🎖@cveNotify
GitHub
GitHub - perfood/couch-auth: Powerful authentication for APIs and apps using CouchDB (or Cloudant) with Node >= 14
Powerful authentication for APIs and apps using CouchDB (or Cloudant) with Node >= 14 - perfood/couch-auth
🚨 CVE-2025-25948
Incorrect access control in the component /rest/staffResource/create of Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows create and modify user accounts, including an Administrator account.
🎖@cveNotify
Incorrect access control in the component /rest/staffResource/create of Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows create and modify user accounts, including an Administrator account.
🎖@cveNotify
🚨 CVE-2025-25949
A stored cross-site scripting (XSS) vulnerability in Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the User ID parameter at /rest/staffResource/update.
🎖@cveNotify
A stored cross-site scripting (XSS) vulnerability in Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the User ID parameter at /rest/staffResource/update.
🎖@cveNotify
🚨 CVE-2025-25950
Incorrect access control in the component /rest/staffResource/update of Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows create and modify user accounts, including an Administrator account.
🎖@cveNotify
Incorrect access control in the component /rest/staffResource/update of Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows create and modify user accounts, including an Administrator account.
🎖@cveNotify
🚨 CVE-2025-25951
An information disclosure vulnerability in the component /rest/cb/executeBasicSearch of Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows attackers to access sensitive user information.
🎖@cveNotify
An information disclosure vulnerability in the component /rest/cb/executeBasicSearch of Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows attackers to access sensitive user information.
🎖@cveNotify
🚨 CVE-2025-25952
An Insecure Direct Object References (IDOR) in the component /getStudemtAllDetailsById?studentId=XX of Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows attackers to access sensitive user information via a crafted API request.
🎖@cveNotify
An Insecure Direct Object References (IDOR) in the component /getStudemtAllDetailsById?studentId=XX of Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 allows attackers to access sensitive user information via a crafted API request.
🎖@cveNotify
🚨 CVE-2025-25953
Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 was discovered to contain an Azure JWT access token exposure. This vulnerability allows authenticated attackers to escalate privileges and access sensitive information.
🎖@cveNotify
Serosoft Solutions Pvt Ltd Academia Student Information System (SIS) EagleR v1.0.118 was discovered to contain an Azure JWT access token exposure. This vulnerability allows authenticated attackers to escalate privileges and access sensitive information.
🎖@cveNotify
🚨 CVE-2022-50368
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dsi: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Patchwork: https://patchwork.freedesktop.org/patch/502668/
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dsi: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Patchwork: https://patchwork.freedesktop.org/patch/502668/
🎖@cveNotify
🚨 CVE-2023-53370
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix memory leak in mes self test
The fences associated with mes queue have to be freed
up during amdgpu_ring_fini.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix memory leak in mes self test
The fences associated with mes queue have to be freed
up during amdgpu_ring_fini.
🎖@cveNotify
🚨 CVE-2023-53371
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create
The memory pointed to by the fs->any pointer is not freed in the error
path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.
Fix by freeing the memory in the error path, thereby making the error path
identical to mlx5e_fs_tt_redirect_any_destroy().
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create
The memory pointed to by the fs->any pointer is not freed in the error
path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.
Fix by freeing the memory in the error path, thereby making the error path
identical to mlx5e_fs_tt_redirect_any_destroy().
🎖@cveNotify
🚨 CVE-2023-53374
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early
Not calling hci_(dis)connect_cfm before deleting conn referred to by a
socket generally results to use-after-free.
When cleaning up SCO connections when the parent ACL is deleted too
early, use hci_conn_failed to do the connection cleanup properly.
We also need to clean up ISO connections in a similar situation when
connecting has started but LE Create CIS is not yet sent, so do it too
here.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early
Not calling hci_(dis)connect_cfm before deleting conn referred to by a
socket generally results to use-after-free.
When cleaning up SCO connections when the parent ACL is deleted too
early, use hci_conn_failed to do the connection cleanup properly.
We also need to clean up ISO connections in a similar situation when
connecting has started but LE Create CIS is not yet sent, so do it too
here.
🎖@cveNotify
🚨 CVE-2023-53377
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent use-after-free by freeing the cfile later
In smb2_compound_op we have a possible use-after-free
which can cause hard to debug problems later on.
This was revealed during stress testing with KASAN enabled
kernel. Fixing it by moving the cfile free call to
a few lines below, after the usage.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent use-after-free by freeing the cfile later
In smb2_compound_op we have a possible use-after-free
which can cause hard to debug problems later on.
This was revealed during stress testing with KASAN enabled
kernel. Fixing it by moving the cfile free call to
a few lines below, after the usage.
🎖@cveNotify
🚨 CVE-2023-53378
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/dpt: Treat the DPT BO as a framebuffer
Currently i915_gem_object_is_framebuffer() doesn't treat the
BO containing the framebuffer's DPT as a framebuffer itself.
This means eg. that the shrinker can evict the DPT BO while
leaving the actual FB BO bound, when the DPT is allocated
from regular shmem.
That causes an immediate oops during hibernate as we
try to rewrite the PTEs inside the already evicted
DPT obj.
TODO: presumably this might also be the reason for the
DPT related display faults under heavy memory pressure,
but I'm still not sure how that would happen as the object
should be pinned by intel_dpt_pin() while in active use by
the display engine...
(cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/dpt: Treat the DPT BO as a framebuffer
Currently i915_gem_object_is_framebuffer() doesn't treat the
BO containing the framebuffer's DPT as a framebuffer itself.
This means eg. that the shrinker can evict the DPT BO while
leaving the actual FB BO bound, when the DPT is allocated
from regular shmem.
That causes an immediate oops during hibernate as we
try to rewrite the PTEs inside the already evicted
DPT obj.
TODO: presumably this might also be the reason for the
DPT related display faults under heavy memory pressure,
but I'm still not sure how that would happen as the object
should be pinned by intel_dpt_pin() while in active use by
the display engine...
(cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)
🎖@cveNotify
🚨 CVE-2025-39874
In the Linux kernel, the following vulnerability has been resolved:
macsec: sync features on RTM_NEWLINK
Syzkaller managed to lock the lower device via ETHTOOL_SFEATURES:
netdev_lock include/linux/netdevice.h:2761 [inline]
netdev_lock_ops include/net/netdev_lock.h:42 [inline]
netdev_sync_lower_features net/core/dev.c:10649 [inline]
__netdev_update_features+0xcb1/0x1be0 net/core/dev.c:10819
netdev_update_features+0x6d/0xe0 net/core/dev.c:10876
macsec_notify+0x2f5/0x660 drivers/net/macsec.c:4533
notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85
call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]
call_netdevice_notifiers net/core/dev.c:2281 [inline]
netdev_features_change+0x85/0xc0 net/core/dev.c:1570
__dev_ethtool net/ethtool/ioctl.c:3469 [inline]
dev_ethtool+0x1536/0x19b0 net/ethtool/ioctl.c:3502
dev_ioctl+0x392/0x1150 net/core/dev_ioctl.c:759
It happens because lower features are out of sync with the upper:
__dev_ethtool (real_dev)
netdev_lock_ops(real_dev)
ETHTOOL_SFEATURES
__netdev_features_change
netdev_sync_upper_features
disable LRO on the lower
if (old_features != dev->features)
netdev_features_change
fires NETDEV_FEAT_CHANGE
macsec_notify
NETDEV_FEAT_CHANGE
netdev_update_features (for each macsec dev)
netdev_sync_lower_features
if (upper_features != lower_features)
netdev_lock_ops(lower) # lower == real_dev
stuck
...
netdev_unlock_ops(real_dev)
Per commit af5f54b0ef9e ("net: Lock lower level devices when updating
features"), we elide the lock/unlock when the upper and lower features
are synced. Makes sure the lower (real_dev) has proper features after
the macsec link has been created. This makes sure we never hit the
situation where we need to sync upper flags to the lower.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
macsec: sync features on RTM_NEWLINK
Syzkaller managed to lock the lower device via ETHTOOL_SFEATURES:
netdev_lock include/linux/netdevice.h:2761 [inline]
netdev_lock_ops include/net/netdev_lock.h:42 [inline]
netdev_sync_lower_features net/core/dev.c:10649 [inline]
__netdev_update_features+0xcb1/0x1be0 net/core/dev.c:10819
netdev_update_features+0x6d/0xe0 net/core/dev.c:10876
macsec_notify+0x2f5/0x660 drivers/net/macsec.c:4533
notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85
call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]
call_netdevice_notifiers net/core/dev.c:2281 [inline]
netdev_features_change+0x85/0xc0 net/core/dev.c:1570
__dev_ethtool net/ethtool/ioctl.c:3469 [inline]
dev_ethtool+0x1536/0x19b0 net/ethtool/ioctl.c:3502
dev_ioctl+0x392/0x1150 net/core/dev_ioctl.c:759
It happens because lower features are out of sync with the upper:
__dev_ethtool (real_dev)
netdev_lock_ops(real_dev)
ETHTOOL_SFEATURES
__netdev_features_change
netdev_sync_upper_features
disable LRO on the lower
if (old_features != dev->features)
netdev_features_change
fires NETDEV_FEAT_CHANGE
macsec_notify
NETDEV_FEAT_CHANGE
netdev_update_features (for each macsec dev)
netdev_sync_lower_features
if (upper_features != lower_features)
netdev_lock_ops(lower) # lower == real_dev
stuck
...
netdev_unlock_ops(real_dev)
Per commit af5f54b0ef9e ("net: Lock lower level devices when updating
features"), we elide the lock/unlock when the upper and lower features
are synced. Makes sure the lower (real_dev) has proper features after
the macsec link has been created. This makes sure we never hit the
situation where we need to sync upper flags to the lower.
🎖@cveNotify
🚨 CVE-2025-39884
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix subvolume deletion lockup caused by inodes xarray race
There is a race condition between inode eviction and inode caching that
can cause a live struct btrfs_inode to be missing from the root->inodes
xarray. Specifically, there is a window during evict() between the inode
being unhashed and deleted from the xarray. If btrfs_iget() is called
for the same inode in that window, it will be recreated and inserted
into the xarray, but then eviction will delete the new entry, leaving
nothing in the xarray:
Thread 1 Thread 2
---------------------------------------------------------------
evict()
remove_inode_hash()
btrfs_iget_path()
btrfs_iget_locked()
btrfs_read_locked_inode()
btrfs_add_inode_to_root()
destroy_inode()
btrfs_destroy_inode()
btrfs_del_inode_from_root()
__xa_erase
In turn, this can cause issues for subvolume deletion. Specifically, if
an inode is in this lost state, and all other inodes are evicted, then
btrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely.
If the lost inode has a delayed_node attached to it, then when
btrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(),
it will loop forever because the delayed_nodes xarray will never become
empty (unless memory pressure forces the inode out). We saw this
manifest as soft lockups in production.
Fix it by only deleting the xarray entry if it matches the given inode
(using __xa_cmpxchg()).
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix subvolume deletion lockup caused by inodes xarray race
There is a race condition between inode eviction and inode caching that
can cause a live struct btrfs_inode to be missing from the root->inodes
xarray. Specifically, there is a window during evict() between the inode
being unhashed and deleted from the xarray. If btrfs_iget() is called
for the same inode in that window, it will be recreated and inserted
into the xarray, but then eviction will delete the new entry, leaving
nothing in the xarray:
Thread 1 Thread 2
---------------------------------------------------------------
evict()
remove_inode_hash()
btrfs_iget_path()
btrfs_iget_locked()
btrfs_read_locked_inode()
btrfs_add_inode_to_root()
destroy_inode()
btrfs_destroy_inode()
btrfs_del_inode_from_root()
__xa_erase
In turn, this can cause issues for subvolume deletion. Specifically, if
an inode is in this lost state, and all other inodes are evicted, then
btrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely.
If the lost inode has a delayed_node attached to it, then when
btrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(),
it will loop forever because the delayed_nodes xarray will never become
empty (unless memory pressure forces the inode out). We saw this
manifest as soft lockups in production.
Fix it by only deleting the xarray entry if it matches the given inode
(using __xa_cmpxchg()).
🎖@cveNotify
🚨 CVE-2025-39890
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix memory leak in ath12k_service_ready_ext_event
Currently, in ath12k_service_ready_ext_event(), svc_rdy_ext.mac_phy_caps
is not freed in the failure case, causing a memory leak. The following
trace is observed in kmemleak:
unreferenced object 0xffff8b3eb5789c00 (size 1024):
comm "softirq", pid 0, jiffies 4294942577
hex dump (first 32 bytes):
00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{...
01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8..
backtrace (crc 44e1c357):
__kmalloc_noprof+0x30b/0x410
ath12k_wmi_mac_phy_caps_parse+0x84/0x100 [ath12k]
ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k]
ath12k_wmi_svc_rdy_ext_parse+0x308/0x4c0 [ath12k]
ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k]
ath12k_service_ready_ext_event.isra.0+0x44/0xd0 [ath12k]
ath12k_wmi_op_rx+0x2eb/0xd70 [ath12k]
ath12k_htc_rx_completion_handler+0x1f4/0x330 [ath12k]
ath12k_ce_recv_process_cb+0x218/0x300 [ath12k]
ath12k_pci_ce_workqueue+0x1b/0x30 [ath12k]
process_one_work+0x219/0x680
bh_worker+0x198/0x1f0
tasklet_action+0x13/0x30
handle_softirqs+0xca/0x460
__irq_exit_rcu+0xbe/0x110
irq_exit_rcu+0x9/0x30
Free svc_rdy_ext.mac_phy_caps in the error case to fix this memory leak.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix memory leak in ath12k_service_ready_ext_event
Currently, in ath12k_service_ready_ext_event(), svc_rdy_ext.mac_phy_caps
is not freed in the failure case, causing a memory leak. The following
trace is observed in kmemleak:
unreferenced object 0xffff8b3eb5789c00 (size 1024):
comm "softirq", pid 0, jiffies 4294942577
hex dump (first 32 bytes):
00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{...
01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8..
backtrace (crc 44e1c357):
__kmalloc_noprof+0x30b/0x410
ath12k_wmi_mac_phy_caps_parse+0x84/0x100 [ath12k]
ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k]
ath12k_wmi_svc_rdy_ext_parse+0x308/0x4c0 [ath12k]
ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k]
ath12k_service_ready_ext_event.isra.0+0x44/0xd0 [ath12k]
ath12k_wmi_op_rx+0x2eb/0xd70 [ath12k]
ath12k_htc_rx_completion_handler+0x1f4/0x330 [ath12k]
ath12k_ce_recv_process_cb+0x218/0x300 [ath12k]
ath12k_pci_ce_workqueue+0x1b/0x30 [ath12k]
process_one_work+0x219/0x680
bh_worker+0x198/0x1f0
tasklet_action+0x13/0x30
handle_softirqs+0xca/0x460
__irq_exit_rcu+0xbe/0x110
irq_exit_rcu+0x9/0x30
Free svc_rdy_ext.mac_phy_caps in the error case to fix this memory leak.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
🎖@cveNotify
🚨 CVE-2025-39896
In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Prevent recovery work from being queued during device removal
Use disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()
to ensure that no new recovery work items can be queued after device
removal has started. Previously, recovery work could be scheduled even
after canceling existing work, potentially leading to use-after-free
bugs if recovery accessed freed resources.
Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to better
reflect its new behavior.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Prevent recovery work from being queued during device removal
Use disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()
to ensure that no new recovery work items can be queued after device
removal has started. Previously, recovery work could be scheduled even
after canceling existing work, potentially leading to use-after-free
bugs if recovery accessed freed resources.
Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to better
reflect its new behavior.
🎖@cveNotify
🚨 CVE-2025-39897
In the Linux kernel, the following vulnerability has been resolved:
net: xilinx: axienet: Add error handling for RX metadata pointer retrieval
Add proper error checking for dmaengine_desc_get_metadata_ptr() which
can return an error pointer and lead to potential crashes or undefined
behaviour if the pointer retrieval fails.
Properly handle the error by unmapping DMA buffer, freeing the skb and
returning early to prevent further processing with invalid data.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: xilinx: axienet: Add error handling for RX metadata pointer retrieval
Add proper error checking for dmaengine_desc_get_metadata_ptr() which
can return an error pointer and lead to potential crashes or undefined
behaviour if the pointer retrieval fails.
Properly handle the error by unmapping DMA buffer, freeing the skb and
returning early to prevent further processing with invalid data.
🎖@cveNotify
🚨 CVE-2025-39899
In the Linux kernel, the following vulnerability has been resolved:
mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE
With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using
kmap_local_page(), which requires unmapping in Last-In-First-Out order.
The current code maps dst_pte first, then src_pte, but unmaps them in the
same order (dst_pte, src_pte), violating the LIFO requirement. This
causes the warning in kunmap_local_indexed():
WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c
addr \!= __fix_to_virt(FIX_KMAP_BEGIN + idx)
Fix this by reversing the unmap order to respect LIFO ordering.
This issue follows the same pattern as similar fixes:
- commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order")
- commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfs_rename")
Both of which addressed the same fundamental requirement that kmap_local
operations must follow LIFO ordering.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE
With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using
kmap_local_page(), which requires unmapping in Last-In-First-Out order.
The current code maps dst_pte first, then src_pte, but unmaps them in the
same order (dst_pte, src_pte), violating the LIFO requirement. This
causes the warning in kunmap_local_indexed():
WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c
addr \!= __fix_to_virt(FIX_KMAP_BEGIN + idx)
Fix this by reversing the unmap order to respect LIFO ordering.
This issue follows the same pattern as similar fixes:
- commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order")
- commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfs_rename")
Both of which addressed the same fundamental requirement that kmap_local
operations must follow LIFO ordering.
🎖@cveNotify
🚨 CVE-2006-5983
Multiple cross-site scripting (XSS) vulnerabilities in JBMC Software DirectAdmin 1.28.1 allow remote authenticated users to inject arbitrary web script or HTML via the (1) user parameter to (a) CMD_SHOW_RESELLER or (b) CMD_SHOW_USER in the Admin level; the (2) TYPE parameter to (c) CMD_TICKET_CREATE or (d) CMD_TICKET, the (3) user parameter to (e) CMD_EMAIL_FORWARDER_MODIFY, (f) CMD_EMAIL_VACATION_MODIFY, or (g) CMD_FTP_SHOW, and the (4) name parameter to (h) CMD_EMAIL_LIST in the User level; or the (5) user parameter to (i) CMD_SHOW_USER in the Reseller level.
🎖@cveNotify
Multiple cross-site scripting (XSS) vulnerabilities in JBMC Software DirectAdmin 1.28.1 allow remote authenticated users to inject arbitrary web script or HTML via the (1) user parameter to (a) CMD_SHOW_RESELLER or (b) CMD_SHOW_USER in the Admin level; the (2) TYPE parameter to (c) CMD_TICKET_CREATE or (d) CMD_TICKET, the (3) user parameter to (e) CMD_EMAIL_FORWARDER_MODIFY, (f) CMD_EMAIL_VACATION_MODIFY, or (g) CMD_FTP_SHOW, and the (4) name parameter to (h) CMD_EMAIL_LIST in the User level; or the (5) user parameter to (i) CMD_SHOW_USER in the Reseller level.
🎖@cveNotify