Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: reject zero bucket types in crush_decode<br /> <br /> CRUSH bucket type 0 is reserved for devices. The mapper relies on<br /> that invariant and uses type 0 to identify leaf devices.<br /> <br /> If crush_decode() accepts a bucket with type 0, a malformed CRUSH map<br /> can make the mapper treat a negative bucket ID as a device and pass it<br /> to is_out(), which then indexes the OSD weight array with a negative<br /> value.<br /> <br /> Reject zero bucket types while decoding the CRUSH map so the invalid<br /> state never reaches the mapper.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Reject monmaps advertising zero monitors<br /> <br /> A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a<br /> monitor to the client. This monmap contains information about the<br /> existing monitors in the cluster. Currently, a monmap indicating that<br /> there are zero monitors in the cluster is treated as valid. However, it<br /> is impossible to have zero monitors in the cluster and still receive a<br /> valid monmap from a monitor. Therefore, such a monmap must be corrupted<br /> and should be treated as invalid. Furthermore, a monmap with a monitor<br /> count of zero can subsequently crash the client when attempting to open<br /> a session with a monitor in __open_session(). This happens because the<br /> "BUG_ON(monc-&gt;monmap-&gt;num_mon CEPH_MAX_MON.<br /> <br /> [ idryomov: drop "log output for unusual values of num_mon" part ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: refresh auth-&gt;authorizer_buf{,_len} after authorizer update<br /> <br /> ceph_x_create_authorizer() caches au-&gt;buf-&gt;vec.iov_base and<br /> au-&gt;buf-&gt;vec.iov_len in struct ceph_auth_handshake. These<br /> cached values are then used by the messenger connect code when<br /> sending the authorizer.<br /> <br /> ceph_x_update_authorizer() can rebuild the authorizer when a newer<br /> service ticket is available. If the rebuilt authorizer no longer<br /> fits in the existing buffer, ceph_x_build_authorizer() drops its<br /> reference to au-&gt;buf and allocates a new one. If this is the final<br /> reference, ceph_buffer_put() frees the old ceph_buffer and its<br /> vec.iov_base, but auth-&gt;authorizer_buf still points at that freed<br /> memory.<br /> <br /> A subsequent msgr1 reconnect can therefore queue the stale pointer<br /> and trigger a KASAN slab-use-after-free in _copy_from_iter() while<br /> tcp_sendmsg() copies the authorizer.<br /> <br /> Refresh auth-&gt;authorizer_buf and auth-&gt;authorizer_buf_len after a<br /> successful authorizer rebuild so the messenger sends the current<br /> buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: guard missing CRUSH type name lookup<br /> <br /> Localized read selection can walk a parent bucket whose name exists in<br /> the CRUSH map while its type has no matching entry in type_names.<br /> get_immediate_parent() then dereferences a NULL type_cn and passes an<br /> invalid pointer into strcmp(), causing a null-ptr-deref.<br /> <br /> Skip such malformed parent buckets unless both the bucket name and type<br /> name metadata are present. This keeps malformed hierarchy data from<br /> crashing locality lookup and safely falls back to "not local".<br /> <br /> [ idryomov: add WARN_ON_ONCE ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: fix out-of-bounds bitmap_set() with zero-length range<br /> <br /> ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk<br /> as (off + len - 1) &gt;&gt; i_blkbits. When off is 0 and len is 0, the<br /> unsigned subtraction underflows to SIZE_MAX, producing a huge<br /> last_blk and nr_blks value that causes bitmap_set() to write far<br /> beyond the ifs-&gt;state allocation.<br /> <br /> Regarding ifs_set_range_uptodate(), it is temporarily safe because len<br /> cannot be passed in as 0. However, for ifs_set_range_dirty() this is<br /> reachable from __iomap_write_end(): when copy_folio_from_iter_atomic()<br /> returns 0 (e.g. user buffer fault) and the folio is already uptodate,<br /> the guard at the top of __iomap_write_end() does not trigger because<br /> !folio_test_uptodate() is false, and iomap_set_range_dirty() is called<br /> with copied == 0.<br /> <br /> Add a !len guard to both functions before the computation, so that a<br /> zero-length range is a no-op.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: preserve ACL_DONT_CACHE state in forget_cached_acl()<br /> <br /> The ACL_DONT_CACHE state is meant to be a constant state for the inode<br /> for filesystems that want to opt out of posix acl caching.<br /> <br /> Commit facd61053cff1 ("fuse: fixes after adapting to new posix acl api")<br /> used this facility to opt out of posix acl caching for fuse inodes with<br /> fuse server that does not negotiate FUSE_POSIX_ACL (fc-&gt;posix_acl).<br /> <br /> The commit also takes care to gate the forget_all_cached_acls() call in<br /> fuse_set_acl() on fc-&gt;posix_acl because there is no need for it, but<br /> there are other placed in fuse code which call forget_all_cached_acls()<br /> unconditional to fc-&gt;posix_acl and those cause the loss of the<br /> ACL_DONT_CACHE state.<br /> <br /> This is not only a functional bug. Properly timed, a get_acl() from this<br /> fuse filesystem can return a stale cached value, as was observed in tests,<br /> because set_acl() does not invalidate the unintentional acl cache.<br /> <br /> We could fix this in fuse, but it actually makes no sense for the vfs<br /> helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so<br /> let it not do that to fix fuse and future users of ACL_DONT_CACHE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: slip: serialize receive against buffer reallocation<br /> <br /> sl_realloc_bufs() replaces rbuff and updates buffsize while holding<br /> sl-&gt;lock. slip_receive_buf() reads those fields and writes through rbuff<br /> without holding the lock.<br /> <br /> An MTU change can therefore race with receive processing. An MTU shrink<br /> can expose the new smaller rbuff with the old larger bound, causing an<br /> out-of-bounds write. A receive callback which already loaded the old<br /> rbuff can instead continue writing after that buffer has been freed.<br /> <br /> Serialize receive processing with sl_realloc_bufs() by holding sl-&gt;lock<br /> while consuming each receive batch.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phonet: pep: fix use-after-free in pep_get_sb()<br /> <br /> pep_get_sb() doesn&amp;#39;t consider that pskb_may_pull() might have relocated<br /> the skb data, and continue to access the older pointer, causing UAF.<br /> <br /> Reproduced under KASAN:<br /> <br /> BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0<br /> Read of size 1 at addr ff11000105510f50 by task repro/157<br /> pep_get_sb+0x234/0x3b0<br /> pipe_handler_do_rcv+0x5f7/0xa10<br /> pep_do_rcv+0x203/0x410<br /> __sk_receive_skb+0x471/0x4a0<br /> phonet_rcv+0x5b3/0x6c0<br /> __netif_receive_skb+0xcc/0x1d0<br /> <br /> Refetch the header with skb_header_pointer() after pskb_may_pull(), so<br /> the possibly stale pointer is no longer dereferenced. There are better<br /> ways to solve this, but, this is the less instrusive one.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Add global mutex to serialize trace_parser access<br /> <br /> In ftrace, the trace_parser structure is allocated and initialized when<br /> a trace file is opened, and is subsequently used across write and release<br /> handlers to parse user input.<br /> <br /> The affected handler paths and their specific functions are:<br /> - Open paths: ftrace_regex_open(), ftrace_graph_open()<br /> - Write paths: ftrace_regex_write(), ftrace_graph_write()<br /> - Release paths: ftrace_regex_release(), ftrace_graph_release()<br /> <br /> If userspace opens a trace file descriptor and shares it across multiple<br /> threads, concurrent write calls will race on the parser&amp;#39;s internal state,<br /> specifically the &amp;#39;idx&amp;#39;, &amp;#39;cont&amp;#39;, and &amp;#39;buffer&amp;#39; fields, leading to corrupted<br /> input or undefined behavior.<br /> <br /> Fix this by adding a global mutex, parser_lock, to serialize all access<br /> to trace_parser across write and release paths, preventing concurrent<br /> corruption of parser state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: Avoid dynamic allocation in fscrypt_get_devices()<br /> <br /> When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls<br /> fscrypt_get_devices() to get the filesystem&amp;#39;s list of block devices,<br /> then iterates over them and calls blk_crypto_config_supported(),<br /> blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one.<br /> <br /> Currently, the block device pointers are placed in a dynamically<br /> allocated array. This dynamic allocation is problematic because:<br /> <br /> - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call<br /> site when it&amp;#39;s invoked for inode eviction under direct reclaim.<br /> <br /> - fscrypt_destroy_inline_crypt_key() doesn&amp;#39;t handle the failure. It<br /> just zeroizes and frees the blk_crypto_key without calling<br /> blk_crypto_evict_key(). That causes a use-after-free.<br /> <br /> For now, let&amp;#39;s fix this in the straightforward and easily-backportable<br /> way by switching to an on-stack array. Currently the fscrypt<br /> multi-device functionality is used only by f2fs, which has a hardcoded<br /> limit of 8 block devices. An on-stack array works fine for that.<br /> <br /> (Of course, this solution won&amp;#39;t scale up to large number of block<br /> devices. For that we&amp;#39;d need a different solution, like moving the block<br /> device iteration into the filesystem. Or in the case of btrfs, which<br /> will only support blk-crypto-fallback, we should make it just call<br /> blk-crypto-fallback directly, so the block devices won&amp;#39;t be needed.)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: Add missing superblock check in find_or_insert_direct_key()<br /> <br /> The legacy &amp;#39;fscrypt_direct_keys&amp;#39; table caches master keys that are used<br /> by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY.<br /> It&amp;#39;s just a global table for all filesystems (since the keys can be<br /> provided by the legacy process-subscribed keyrings mechanism, which<br /> makes it difficult to reuse super_block::s_master_keys).<br /> <br /> The entries in it (&amp;#39;struct fscrypt_direct_key&amp;#39;) do contain a super_block<br /> pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when<br /> the last inode that references the key is evicted.<br /> <br /> However, when finding the fscrypt_direct_key for an inode, we weren&amp;#39;t<br /> actually comparing the super_block pointer. As a result, inodes with<br /> different super_blocks could point to the same fscrypt_direct_key. That<br /> could extend the lifetime of a fscrypt_direct_key beyond the<br /> super_block it points to, causing a use-after-free later.<br /> <br /> Fix this by creating distinct fscrypt_direct_key structs for distinct<br /> super_block structs.<br /> <br /> Note that this problem doesn&amp;#39;t exist in the v2 policy equivalent<br /> ("per-mode keys"), since the data structures there are per super_block.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gro: fix double aggregation of flush-marked skbs<br /> <br /> Commit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a GSO<br /> packet.") added a flush check to skb_gro_receive(), but<br /> skb_gro_receive_list() lacks the same validation.<br /> <br /> As a result, packets marked with NAPI_GRO_CB(skb)-&gt;flush may still be<br /> re-aggregated.<br /> <br /> This allows already-GRO&amp;#39;d packets with existing frag_list to be<br /> re-aggregated into a new GRO session, corrupting the frag_list chain<br /> structure. When skb_segment() attempts to unpack these malformed packets,<br /> it encounters invalid state and triggers a kernel panic.<br /> <br /> Scenario (Tethering/Device forwarding):<br /> 1. Driver: Generated aggregated packet P1 via LRO with frag_list<br /> 2. Dev A: Receives aggregated fraglist packet and flush flag set<br /> 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called<br /> 4. Missing flush check allows re-aggregation despite flush flag<br /> 5. Frag_list chain becomes corrupted (loops or dangling refs)<br /> 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list<br /> <br /> Root cause in skb_segment():<br /> The check at line ~4891:<br /> if (hsize = nfrags &amp;&amp; skb_headlen(list_skb) &amp;&amp;<br /> (skb_headlen(list_skb) == len || sg)) {<br /> <br /> When frag_list is corrupted by double aggregation, when list_skb is<br /> a NULL pointer from skb-&gt;next, skb_headlen(list_skb) dereference<br /> NULL/corrupted pointers occurs.<br /> <br /> Call Trace:<br /> skb_headlen(NULL skb)<br /> skb_segment<br /> tcp_gso_segment<br /> tcp4_gso_segment<br /> inet_gso_segment<br /> skb_mac_gso_segment<br /> __skb_gso_segment<br /> skb_gso_segment<br /> validate_xmit_skb<br /> validate_xmit_skb_list<br /> sch_direct_xmit<br /> qdisc_restart<br /> __qdisc_run<br /> qdisc_run<br /> net_tx_action<br /> <br /> Fix: Add NAPI_GRO_CB(skb)-&gt;flush validation to the early-return check in<br /> skb_gro_receive_list(), matching the defensive programming pattern of<br /> skb_gro_receive().