| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition
The acp3x_5682_init() function did not check the return value of
clk_get(), which could lead to dereferencing error pointers in
rt5682_clk_enable().
Fix this by:
1. Changing clk_get() to the device-managed devm_clk_get().
2. Adding proper IS_ERR() checks for both clock acquisitions. |
| In the Linux kernel, the following vulnerability has been resolved:
liveupdate: luo_file: remember retrieve() status
LUO keeps track of successful retrieve attempts on a LUO file. It does so
to avoid multiple retrievals of the same file. Multiple retrievals cause
problems because once the file is retrieved, the serialized data
structures are likely freed and the file is likely in a very different
state from what the code expects.
The retrieve boolean in struct luo_file keeps track of this, and is passed
to the finish callback so it knows what work was already done and what it
has left to do.
All this works well when retrieve succeeds. When it fails,
luo_retrieve_file() returns the error immediately, without ever storing
anywhere that a retrieve was attempted or what its error code was. This
results in an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to userspace,
but nothing prevents it from trying this again.
The retry is problematic for much of the same reasons listed above. The
file is likely in a very different state than what the retrieve logic
normally expects, and it might even have freed some serialization data
structures. Attempting to access them or free them again is going to
break things.
For example, if memfd managed to restore 8 of its 10 folios, but fails on
the 9th, a subsequent retrieve attempt will try to call
kho_restore_folio() on the first folio again, and that will fail with a
warning since it is an invalid operation.
Apart from the retry, finish() also breaks. Since on failure the
retrieved bool in luo_file is never touched, the finish() call on session
close will tell the file handler that retrieve was never attempted, and it
will try to access or free the data structures that might not exist, much
in the same way as the retry attempt.
There is no sane way of attempting the retrieve again. Remember the error
retrieve returned and directly return it on a retry. Also pass this
status code to finish() so it can make the right decision on the work it
needs to do.
This is done by changing the bool to an integer. A value of 0 means
retrieve was never attempted, a positive value means it succeeded, and a
negative value means it failed and the error code is the value. |
| A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high. |
| In the Linux kernel, the following vulnerability has been resolved:
nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()
Add check for the return value of nfp_app_ctrl_msg_alloc() in
nfp_bpf_cmsg_alloc() to prevent null pointer dereference. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix RELEASE_LOCKOWNER
The test on so_count in nfsd4_release_lockowner() is nonsense and
harmful. Revert to using check_for_locks(), changing that to not sleep.
First: harmful.
As is documented in the kdoc comment for nfsd4_release_lockowner(), the
test on so_count can transiently return a false positive resulting in a
return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is
clearly a protocol violation and with the Linux NFS client it can cause
incorrect behaviour.
If RELEASE_LOCKOWNER is sent while some other thread is still
processing a LOCK request which failed because, at the time that request
was received, the given owner held a conflicting lock, then the nfsd
thread processing that LOCK request can hold a reference (conflock) to
the lock owner that causes nfsd4_release_lockowner() to return an
incorrect error.
The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it
never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so
it knows that the error is impossible. It assumes the lock owner was in
fact released so it feels free to use the same lock owner identifier in
some later locking request.
When it does reuse a lock owner identifier for which a previous RELEASE
failed, it will naturally use a lock_seqid of zero. However the server,
which didn't release the lock owner, will expect a larger lock_seqid and
so will respond with NFS4ERR_BAD_SEQID.
So clearly it is harmful to allow a false positive, which testing
so_count allows.
The test is nonsense because ... well... it doesn't mean anything.
so_count is the sum of three different counts.
1/ the set of states listed on so_stateids
2/ the set of active vfs locks owned by any of those states
3/ various transient counts such as for conflicting locks.
When it is tested against '2' it is clear that one of these is the
transient reference obtained by find_lockowner_str_locked(). It is not
clear what the other one is expected to be.
In practice, the count is often 2 because there is precisely one state
on so_stateids. If there were more, this would fail.
In my testing I see two circumstances when RELEASE_LOCKOWNER is called.
In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in
all the lock states being removed, and so the lockowner being discarded
(it is removed when there are no more references which usually happens
when the lock state is discarded). When nfsd4_release_lockowner() finds
that the lock owner doesn't exist, it returns success.
The other case shows an so_count of '2' and precisely one state listed
in so_stateid. It appears that the Linux client uses a separate lock
owner for each file resulting in one lock state per lock owner, so this
test on '2' is safe. For another client it might not be safe.
So this patch changes check_for_locks() to use the (newish)
find_any_file_locked() so that it doesn't take a reference on the
nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With
this check is it safe to restore the use of check_for_locks() rather
than testing so_count against the mysterious '2'. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcm_loop: Drain commands in target_reset handler
tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS
without draining any in-flight commands. The SCSI EH documentation
(scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver
has made lower layers "forget about timed out scmds" and is ready for new
commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug,
mpi3mr) enforces this by draining or completing outstanding commands before
returning SUCCESS.
Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight
scsi_cmnd structures for recovery commands (e.g. TUR) while the target core
still has async completion work queued for the old se_cmd. The memset in
queuecommand zeroes se_lun and lun_ref_active, causing
transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN
reference prevents transport_clear_lun_ref() from completing, hanging
configfs LUN unlink forever in D-state:
INFO: task rm:264 blocked for more than 122 seconds.
rm D 0 264 258 0x00004000
Call Trace:
__schedule+0x3d0/0x8e0
schedule+0x36/0xf0
transport_clear_lun_ref+0x78/0x90 [target_core_mod]
core_tpg_remove_lun+0x28/0xb0 [target_core_mod]
target_fabric_port_unlink+0x50/0x60 [target_core_mod]
configfs_unlink+0x156/0x1f0 [configfs]
vfs_unlink+0x109/0x290
do_unlinkat+0x1d5/0x2d0
Fix this by making tcm_loop_target_reset() actually drain commands:
1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that
the target core knows about (those not yet CMD_T_COMPLETE).
2. Use blk_mq_tagset_busy_iter() to iterate all started requests and
flush_work() on each se_cmd — this drains any deferred completion work
for commands that already had CMD_T_COMPLETE set before the TMR (which
the TMR skips via __target_check_io_state()). This is the same pattern
used by mpi3mr, scsi_debug, and libsas to drain outstanding commands
during reset. |
| Linux kernel before 2.4.21 allows local users to cause a denial of service (kernel panic) via asynchronous input or output on a FIFO special file. |
| ImageMagick before 6.3.5-9 allows context-dependent attackers to cause a denial of service via a crafted image file that triggers (1) an infinite loop in the ReadDCMImage function, related to ReadBlobByte function calls; or (2) an infinite loop in the ReadXCFImage function, related to ReadBlobMSBLong function calls. |
| KMPlayer 2.9.3.1210 and earlier allows remote attackers to cause a denial of service (CPU consumption) via a .avi file with certain large "indx truck size" and nEntriesInuse values. |
| Memory leak in TIBCO Rendezvous (RV) daemon (rvd) 7.5.2, 7.5.3 and 7.5.4 allows remote attackers to cause a denial of service (memory consumption) via a packet with a length field of zero, a different vulnerability than CVE-2006-2830. |
| The (a) imagearc and (b) imagefilledarc functions in GD Graphics Library (libgd) before 2.0.35 allow attackers to cause a denial of service (CPU consumption) via a large (1) start or (2) end angle degree value. |
| Multiple stack-based buffer overflows in Microsoft Visual Basic 6 allow user-assisted remote attackers to cause a denial of service (CPU consumption) or execute arbitrary code via a Visual Basic Project (vbp) file with a long (1) Description or (2) Company Name (VersionCompanyName) field. |
| The Oracle Discoverer servlet in Oracle Application Server 9.0.4.3, 10.1.2.0.2, and 10.1.2.2.0 allows remote attackers to shut down an Oracle TNS Listener via a TNS STOP command in a request that uses the database/TNS alias, aka AS01. |
| The Network Processing Unit (NPU) in the Cisco Wireless LAN Controller (WLC) before 3.2.171.5, 4.0.x before 4.0.206.0, and 4.1.x allows remote attackers on a local wireless network to cause a denial of service (loss of packet forwarding) via (1) crafted SNAP packets, (2) malformed 802.11 traffic, or (3) packets with certain header length values, aka Bug IDs CSCsg15901 and CSCsh10841. |
| Cisco Wireless LAN Controller (WLC) before 3.2.116.21, and 4.0.x before 4.0.155.0, allows remote attackers on a local network to cause a denial of service (device crash) via malformed Ethernet traffic. |
| File descriptor leak in the PDF handler in Clam AntiVirus (ClamAV) allows remote attackers to cause a denial of service via a crafted PDF file. |
| The do_ipv6_setsockopt function in net/ipv6/ipv6_sockglue.c in Linux kernel before 2.6.20, and possibly other versions, allows local users to cause a denial of service (oops) by calling setsockopt with the IPV6_RTHDR option name and possibly a zero option length or invalid option value, which triggers a NULL pointer dereference. |
| ecma/kjs_html.cpp in KDE JavaScript (KJS), as used in Konqueror in KDE 3.5.5, allows remote attackers to cause a denial of service (crash) by accessing the content of an iframe with an ftp:// URI in the src attribute, probably due to a NULL pointer dereference. |
| Unspecified kernel GDI functions in Microsoft Windows 2000 SP4; XP SP2; and Server 2003 Gold, SP1, and SP2 allows user-assisted remote attackers to cause a denial of service (possibly persistent restart) via a crafted Windows Metafile (WMF) image that causes an invalid dereference of an offset in a kernel structure, a related issue to CVE-2005-4560. |
| Apache SpamAssassin before 3.1.8 allows remote attackers to cause a denial of service via long URLs in malformed HTML, which triggers "massive memory usage." |
