Max Kellermann

The issue arises when netfslib attempts to copy data on behalf of nfs, creating a new write request and calling `nfs netfs init request()` with a NULL file pointer, causing `nfs file open context()` to fail. The fix involves returning if no file pointer is given and emitting a warning for non-copy-to-cache requests. Additionally, `nfs netfs free request()` is modified to not free the context if the pointer is NULL.

The issue arises in the Linux kernel's netfs subsystem, specifically when handling the copy to cache on write-begin operation for ceph filesystems. At the end of `netfs unlock read folio()`, where folios are marked for copying to the cache, the `folio queue` struct has its entry pointing to the folio cleared. This causes a problem for `netfs pgpriv2 write to the cache()`, which expects to traverse the `folio queue` list to find relevant folios, leading to a hang. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. Technical details about exploitation include: - The `netfs unlock read folio()` function - The `folio queue` struct - The `netfs pgpriv2 write to the cache()` function - The `PG private 2` variable

The issue arises when caching for a cookie is temporarily disabled, and netfslib uses the deprecated PG private 2 method. In such cases, `netfs advance write()` fails to properly handle the situation, leading to discarded requests and folios being left with `PG private 2` set. This problem was identified by running the generic/013 xfstest against ceph with an active cache.

A credential leak issue has been resolved in the Linux kernel. The problem occurred because `get current cred()` increments the reference counter, but the corresponding `put cred()` call was missing in the `ceph mds check access()` function.

A NULL pointer dereference bug has been identified in the Linux kernel due to a data race. This issue occurs when the `fscache cookie state machine()` function is slow and still running while another process invokes `fscache unuse cookie()`, leading to a `fscache cookie lru do one()` call that sets the `FSCACHE COOKIE DO LRU DISCARD` flag. This flag is then picked up by `fscache cookie state machine()`, which withdraws the cookie via `cachefiles withdraw cookie()` and clears `cookie->cache priv`. At the same time, another process may invoke `cachefiles prepare write()`, finding a NULL pointer in the code line `struct cachefiles object *object = cachefiles cres object(cres)`, causing a crash. The `n accesses` counter is non-zero during `cachefiles prepare write()` (via `fscache begin operation()`), and the cookie must not be withdrawn until this counter drops to zero. The counter is checked by `fscache cookie state machine()` before switching to certain states, but not for `FSCACHE COOKIE STATE LRU DISCARDING`. This patch adds the missing check, ensuring that with a non-zero access counter, the function returns and the next `fscache end cookie access()` call will queue another `fscache cookie state machine()` call to handle the still-pending `FSCACHE COOKIE DO LRU DISCARD`.

A race condition exists in the Linux kernel's fscache, specifically when handling NFS files. If an NFS file is opened for writing, closed, and then modified locally, the cache contents may not be updated, potentially leading to file corruption. This issue arises when the cookie is in the LOOKING UP state and the request to invalidate doesn't get recorded. The fix involves setting a flag in fscache invalidate() to indicate the need for invalidation when the cookie is in the LOOKING UP state.

The issue allows a local attacker to read private information due to the creation of ~/snap directories in user home directories without specifying owner-only permissions.

The issue is related to a flaw in the libapreq2 multipart parser, which can cause a null pointer dereference, leading to a process crash. A remote attacker could exploit this by sending a specially crafted HTTP request, potentially resulting in a denial of service attack.

An issue exists in the Linux kernel where the `flags` member of the new pipe buffer structure is not properly initialized within the `copy page to iter pipe()` and `push pipe()` functions. This lack of initialization can lead to the presence of stale values, allowing an unprivileged local user to overwrite data in the page cache of arbitrary read-only files, such as `/etc/passwd`. This can be used to inject code from unprivileged processes into privileged ones, resulting in privilege escalation and the acquisition of an elevated shell. Real-world incidents have shown this flaw being used to escalate privileges followed by the use of Discord for command-and-control communications.