CVE-2024-50285 |
Description: In the Linux kernel, the following vulnerability has been resolved:
ksmbd: check outstanding simultaneous SMB operations
If Client send simultaneous SMB operations to ksmbd, It exhausts too much
memory through the "ksmbd_work_cacheā. It will cause OOM issue.
ksmbd has a credit mechanism but it can't handle this problem. This patch
add the check if it exceeds max credits to prevent this problem by assuming
that one smb request consumes at least one credit.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 10th, 2024 (6 months ago)
|
CVE-2024-50283 |
Description: In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp
ksmbd_user_session_put should be called under smb3_preauth_hash_rsp().
It will avoid freeing session before calling smb3_preauth_hash_rsp().
CVSS: LOW (0.0) EPSS Score: 0.04%
December 10th, 2024 (6 months ago)
|
CVE-2024-50263 |
Description: In the Linux kernel, the following vulnerability has been resolved:
fork: only invoke khugepaged, ksm hooks if no error
There is no reason to invoke these hooks early against an mm that is in an
incomplete state.
The change in commit d24062914837 ("fork: use __mt_dup() to duplicate
maple tree in dup_mmap()") makes this more pertinent as we may be in a
state where entries in the maple tree are not yet consistent.
Their placement early in dup_mmap() only appears to have been meaningful
for early error checking, and since functionally it'd require a very small
allocation to fail (in practice 'too small to fail') that'd only occur in
the most dire circumstances, meaning the fork would fail or be OOM'd in
any case.
Since both khugepaged and KSM tracking are there to provide optimisations
to memory performance rather than critical functionality, it doesn't
really matter all that much if, under such dire memory pressure, we fail
to register an mm with these.
As a result, we follow the example of commit d2081b2bf819 ("mm:
khugepaged: make khugepaged_enter() void function") and make ksm_fork() a
void function also.
We only expose the mm to these functions once we are done with them and
only if no error occurred in the fork operation.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 10th, 2024 (6 months ago)
|
CVE-2024-50248 |
Description: In the Linux kernel, the following vulnerability has been resolved:
ntfs3: Add bounds checking to mi_enum_attr()
Added bounds checking to make sure that every attr don't stray beyond
valid memory region.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 10th, 2024 (6 months ago)
|
CVE-2024-50247 |
Description: In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Check if more than chunk-size bytes are written
A incorrectly formatted chunk may decompress into
more than LZNT_CHUNK_SIZE bytes and a index out of bounds
will occur in s_max_off.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 10th, 2024 (6 months ago)
|
CVE-2024-50246 |
Description: In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Add rough attr alloc_size check
CVSS: LOW (0.0) EPSS Score: 0.04%
December 10th, 2024 (6 months ago)
|
CVE-2024-50245 |
Description: In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix possible deadlock in mi_read
Mutex lock with another subclass used in ni_lock_dir().
CVSS: LOW (0.0) EPSS Score: 0.04%
December 10th, 2024 (6 months ago)
|
CVE-2024-50244 |
Description: In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Additional check in ni_clear()
Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to
uninitialized bitmap during replay process.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 10th, 2024 (6 months ago)
|
CVE-2024-50243 |
Description: In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix general protection fault in run_is_mapped_full
Fixed deleating of a non-resident attribute in ntfs_create_inode()
rollback.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 10th, 2024 (6 months ago)
|
CVE-2024-50220 |
Description: In the Linux kernel, the following vulnerability has been resolved:
fork: do not invoke uffd on fork if error occurs
Patch series "fork: do not expose incomplete mm on fork".
During fork we may place the virtual memory address space into an
inconsistent state before the fork operation is complete.
In addition, we may encounter an error during the fork operation that
indicates that the virtual memory address space is invalidated.
As a result, we should not be exposing it in any way to external machinery
that might interact with the mm or VMAs, machinery that is not designed to
deal with incomplete state.
We specifically update the fork logic to defer khugepaged and ksm to the
end of the operation and only to be invoked if no error arose, and
disallow uffd from observing fork events should an error have occurred.
This patch (of 2):
Currently on fork we expose the virtual address space of a process to
userland unconditionally if uffd is registered in VMAs, regardless of
whether an error arose in the fork.
This is performed in dup_userfaultfd_complete() which is invoked
unconditionally, and performs two duties - invoking registered handlers
for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down
userfaultfd_fork_ctx objects established in dup_userfaultfd().
This is problematic, because the virtual address space may not yet be
correctly initialised if an error arose.
The change in commit d24062914837 ("fork: use __mt_dup() to duplicate
maple tree in dup_mmap...
CVSS: LOW (0.0) EPSS Score: 0.05%
December 10th, 2024 (6 months ago)
|