Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/super: fix emergency thaw double-unlock of s_umount<br /> <br /> do_thaw_all() iterates over all superblocks via __iterate_supers()<br /> with SUPER_ITER_EXCL, which acquires s_umount exclusively before<br /> calling the callback and releases it afterwards. However, the<br /> callback do_thaw_all_callback() calls thaw_super_locked() which<br /> unconditionally releases s_umount on every code path. This results<br /> in a second unlock attempt in __iterate_supers() that corrupts the<br /> rwsem state, triggering a DEBUG_RWSEMS warning:<br /> <br /> [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems<br /> [ 182.601865] ------------[ cut here ]------------<br /> [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &amp;&amp; !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty<br /> [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53<br /> [ 182.604578] Modules linked in:<br /> [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy)<br /> [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014<br /> [ 182.606417] Workqueue: events do_thaw_all<br /> [ 182.606750] RIP: 0010:up_write+0xaf/0x170<br /> [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d<br /> [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246<br /> [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870<br /> [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10<br /> [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80<br /> [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000<br /> [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800<br /> [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000<br /> [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0<br /> [ 182.613722] Call Trace:<br /> [ 182.613946] <br /> [ 182.614130] __iterate_supers+0x128/0x150<br /> [ 182.614463] do_thaw_all+0x1b/0x30<br /> [ 182.614759] process_scheduled_works+0xbb/0x3f0<br /> [ 182.615150] ? __pfx_worker_thread+0x10/0x10<br /> [ 182.615499] worker_thread+0x129/0x270<br /> [ 182.615816] ? __pfx_worker_thread+0x10/0x10<br /> [ 182.616201] kthread+0xe2/0x120<br /> [ 182.616469] ? __pfx_kthread+0x10/0x10<br /> [ 182.616792] ret_from_fork+0x15b/0x240<br /> [ 182.617115] ? __pfx_kthread+0x10/0x10<br /> [ 182.617426] ret_from_fork_asm+0x1a/0x30<br /> [ 182.617761] <br /> [ 182.617968] ---[ end trace 0000000000000000 ]---<br /> [ 182.618412] Emergency Thaw complete<br /> <br /> Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount<br /> in the callback via super_lock_excl() before calling<br /> thaw_super_locked(). This matches the locking pattern expected by<br /> thaw_super_locked() and eliminates the double unlock.<br /> <br /> While at it, remove the dead &amp;#39;return;&amp;#39; at the end of<br /> do_thaw_all_callback().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amt: fix use-after-free in AMT delayed works<br /> <br /> When an AMT device is removed, pending delayed works can still access<br /> the freed amt_dev structure, which may result in kernel crashes or<br /> memory corruption.<br /> <br /> amt_dev_stop() cancels req_wq and discovery_wq with<br /> cancel_delayed_work_sync(), but these works can be scheduled again<br /> from event_wq after the cancellation. This allows delayed works to<br /> access the freed amt_dev structure after the netdev has been released.<br /> <br /> The following is a simple race scenario:<br /> <br /> CPU0 CPU1<br /> <br /> amt_dev_stop()<br /> cancel_delayed_work_sync()<br /> amt_event_work()<br /> mod_delayed_work(req_wq)<br /> free netdev<br /> req_wq accesses freed amt_dev<br /> <br /> Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and<br /> discovery_wq from being queued again and wait for running work items<br /> to complete.<br /> <br /> The delayed works are disabled after initialization in<br /> amt_newlink() and enabled only when the device is successfully opened.<br /> This keeps the delayed work lifecycle synchronized with the lifetime<br /> of the AMT device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_elf_fdpic: only honour the first PT_INTERP<br /> <br /> The program header scan handles PT_INTERP from a switch nested in the<br /> scan loop, so its break leaves the switch and not the loop. A binary<br /> carrying more than one PT_INTERP runs the case again and overwrites both<br /> interpreter_name and interpreter. The previous name allocation leaks and<br /> so does the previous interpreter reference, along with the write denial<br /> open_exec() took on it. The denial is never released, so the file stays<br /> unwritable for as long as the system runs.<br /> <br /> An unprivileged caller reaches this with a crafted binary and repeats it<br /> at will. binfmt_elf stops at the first PT_INTERP. Do the same here.<br /> <br /> The flaw dates back to the driver&amp;#39;s introduction in the pre-git history<br /> tree introduced in v2.6.11 by 91808d6ebe39 ("[PATCH] FRV: Add FDPIC ELF<br /> binary format driver").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: remove debugfs files before client teardown<br /> <br /> ceph_destroy_client() tears down the monitor client before removing<br /> the per-client debugfs files. A concurrent read of the monmap debugfs<br /> file can enter monmap_show() after ceph_monc_stop() has freed<br /> monc-&gt;monmap, triggering a use-after-free.<br /> <br /> Remove the debugfs files before stopping the OSD and monitor clients.<br /> debugfs_remove() drains active handlers and prevents new accesses, so<br /> the debugfs callbacks can no longer race the rest of client teardown.

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.

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 ]

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.

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 ]

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.

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.

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.

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.