| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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'. |
| Unspecified vulnerability in Denora IRC Stats Server before 1.4.1 allows remote IRC servers to cause a denial of service (application crash) via a crafted CTCP response. |
| libicu in International Components for Unicode (ICU) 3.8.1 and earlier attempts to process backreferences to the nonexistent capture group zero (aka \0), which might allow context-dependent attackers to read from, or write to, out-of-bounds memory locations, related to corruption of REStackFrames. |
| The FlexGrid ActiveX control in Microsoft Visual Basic 6.0, Visual FoxPro 8.0 SP1 and 9.0 SP1 and SP2, Office FrontPage 2002 SP3, and Office Project 2003 SP3 does not properly handle errors during access to incorrectly initialized objects, which allows remote attackers to execute arbitrary code via a crafted HTML document, related to corruption of the "system state," aka "FlexGrid Control Memory Corruption Vulnerability." |
| Double free vulnerability in the NFS component in Apple Mac OS X 10.4 through 10.4.10 allows remote authenticated users to execute arbitrary code via a crafted AUTH_UNIX RPC packet. |
| The chunk_split function in string.c in PHP 5.2.3 does not properly calculate the needed buffer size due to precision loss when performing integer arithmetic with floating point numbers, which has unknown attack vectors and impact, possibly resulting in a heap-based buffer overflow. NOTE: this is due to an incomplete fix for CVE-2007-2872. |
| Apple Type Services (ATS) in Apple Mac OS X 10.5 before 10.5.6 allows remote attackers to cause a denial of service (infinite loop) via a crafted embedded font in a PDF file. |
| The search-ms protocol handler in Windows Explorer in Microsoft Windows Vista Gold and SP1 and Server 2008 uses untrusted parameter data obtained from incorrect parsing, which allows remote attackers to execute arbitrary code via a crafted HTML document, aka "Windows Search Parsing Vulnerability." |
| GoAhead WebServer before 2.1.1 allows remote attackers to cause a denial of service (CPU consumption) by performing a socket disconnect to terminate a request before it has been fully processed by the server. |
| Unspecified vulnerability in BEA WebLogic Server 6.1 Gold through SP7, 7.0 Gold through SP7, and 8.1 Gold through SP4 allows remote attackers to cause a denial of service (server thread hang) via unspecified vectors. |
| Integer overflow in the xmlSAX2Characters function in libxml2 2.7.2 allows context-dependent attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code via a large XML document. |
| 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. |
| Apple Safari 3.0 and 3.0.1 on Windows XP SP2 allows attackers to cause a denial of service (application crash) via JavaScript that sets the document.location variable, as demonstrated by an empty value of document.location. |
| Safari in Apple iPhone OS 1.0 through 2.1 and iPhone OS for iPod touch 1.1 through 2.1 does not properly handle HTML TABLE elements, which allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted HTML document. |
| The Charts ActiveX control in Microsoft Visual Basic 6.0, Visual Studio .NET 2002 SP1 and 2003 SP1, and Visual FoxPro 8.0 SP1 and 9.0 SP1 and SP2 does not properly handle errors during access to incorrectly initialized objects, which allows remote attackers to execute arbitrary code via a crafted HTML document, related to corruption of the "system state," aka "Charts Control Memory Corruption Vulnerability." |
| The BMP image parser in Sun Java Development Kit (JDK) before 1.5.0_11-b03 and 1.6.x before 1.6.0_01-b06, and Sun Java Runtime Environment in JDK and JRE 6, JDK and JRE 5.0 Update 10 and earlier, SDK and JRE 1.4.2_14 and earlier, and SDK and JRE 1.3.1_19 and earlier, when running on Unix/Linux systems, allows remote attackers to cause a denial of service (JVM hang) via untrusted applets or applications that open arbitrary local files via a crafted BMP file, such as /dev/tty. |
| 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. |
