Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: avoid auth_enable sysctl UAF during netns teardown<br /> <br /> proc_sctp_do_auth() updates the SCTP control socket after changing<br /> net.sctp.auth_enable. The handler gets the per-net SCTP state from<br /> ctl-&gt;data, so an already opened sysctl file can still target a network<br /> namespace while that namespace is being torn down.<br /> <br /> SCTP previously registered its per-net sysctls from sctp_defaults_init(),<br /> while the control socket is created later from sctp_ctrlsock_init(). This<br /> exposed a window during initialization where auth_enable was writable<br /> before net-&gt;sctp.ctl_sock existed, and a teardown window where auth_enable<br /> stayed writable after inet_ctl_sock_destroy() had released the control<br /> socket.<br /> <br /> Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after<br /> sctp_ctl_sock_init() succeeds, and unregister the sysctl table before<br /> destroying the control socket in sctp_ctrlsock_exit(). If sysctl<br /> registration fails after the control socket was created, destroy the<br /> control socket in the same init path.<br /> <br /> Make sctp_sysctl_net_unregister() tolerate a missing header and clear the<br /> saved pointer so init-error and exit paths can safely share the unregister<br /> helper.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_vma_mapped: fix device-private PMD handling<br /> <br /> Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support<br /> device-private entries") introduced the concept of device-private PMD<br /> entries, but did not correctly update the rmap walk code to account for<br /> them.<br /> <br /> As a result, when page_vma_mapped_walk() encounters device-private PMD<br /> entries, it takes no action other than to acquire the PMD lock and exit.<br /> <br /> However this is highly problematic for two reasons - firstly, device<br /> private entries possess a PFN so check_pmd() needs to be called to ensure<br /> an overlapping PFN range.<br /> <br /> Secondly, and more importantly, if PVMW_MIGRATION is set the caller<br /> assumes the returned entry is a migration entry, resulting in memory<br /> corruption when the caller tries to interpret the device private entry as<br /> such.<br /> <br /> In addition, commit 146287290023 ("mm/huge_memory: implement<br /> device-private THP splitting") allowed device private PMDs to be split<br /> like THP mappings, but again did not update this code path.<br /> <br /> As a result, we might race a PMD split prior to acquiring the PMD lock.<br /> <br /> This patch addresses all of these issues by invoking check_pmd(), ensuring<br /> PMVW_MIGRATION is not set and checks whether a split raced us we do for<br /> PMD THP and migration entries.<br /> <br /> Instead of checking for a subset of the cases after taking the pmd_lock(),<br /> put device-private along with pmd_trans_huge() and<br /> pmd_is_migration_entry(). Also remove thp_migration_supported() as it is<br /> already guarded by pmd_is_migration_entry().<br /> <br /> [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Fix multiplication overflow in decode_new_up_state_weight()<br /> <br /> If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted<br /> osdmap, out-of-bounds memory accesses may occur in<br /> decode_new_up_state_weight(). This happens because the bounds check for<br /> the new_state part is based on calculating its length depending on a len<br /> value read from the incoming message. This calculation may overflow<br /> leading to an incorrect bounds check. Subsequently, out-of-bounds reads<br /> may occur when decoding this part.<br /> <br /> This patch switches the multiplication to use check_mul_overflow() to<br /> abort processing the osdmap if an overflow occurred. Therefore,<br /> osdmaps/messages containing large values for len that result in a<br /> multiplication overflow are treated as invalid.<br /> <br /> [ idryomov: rename new_state_len -&gt; new_state_item_size, formatting ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()<br /> <br /> ceph_handle_caps() reads snap_trace_len from the wire-format<br /> ceph_mds_caps header and uses it unconditionally to build a fake<br /> end pointer (snaptrace + snaptrace_len) that is later handed to<br /> ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case:<br /> <br /> snaptrace = h + 1;<br /> snaptrace_len = le32_to_cpu(h-&gt;snap_trace_len);<br /> p = snaptrace + snaptrace_len;<br /> ...<br /> case CEPH_CAP_OP_IMPORT:<br /> if (snaptrace_len) {<br /> ...<br /> if (ceph_update_snap_trace(mdsc, snaptrace,<br /> snaptrace + snaptrace_len,<br /> false, &amp;realm)) { ... }<br /> <br /> ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm<br /> from snaptrace using ceph_decode_need(&amp;p, e, sizeof(*ri), bad)<br /> with the attacker-supplied fake end e == snaptrace + snaptrace_len.<br /> With snaptrace_len == 0xFFFFFFFF the bound check is trivially<br /> satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past<br /> the legitimate msg-&gt;front buffer, and ri-&gt;num_snaps /<br /> ri-&gt;num_prior_parent_snaps then drive further out-of-bounds<br /> reads of the encoded snap arrays.<br /> <br /> The eleven msg_version &gt;= 2 .. msg_version &gt;= 12 decoder blocks<br /> above the op switch each catch this OOB through their<br /> ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit<br /> behind a hdr.version-gated if, so a malicious or compromised<br /> MDS that sets msg-&gt;hdr.version = 1 reaches the IMPORT path with<br /> no version-gated decoder having validated snap_trace_len. The<br /> shape has been present since ceph_handle_caps() was introduced.<br /> <br /> Validate snap_trace_len against the message front buffer before<br /> consuming it, using the canonical ceph_decode_need() / ceph_has_room()<br /> helper. The helper bounds the length with subtraction (n = p) rather than pointer addition, so it is wrap-safe<br /> for the attacker-controlled u32 length on 32-bit builds where<br /> p + snap_trace_len could overflow the address space. This matches the<br /> rest of the ceph decode path (e.g. the pool_ns_len check a few lines<br /> below), and the existing goto bad cleanup already covers this exit<br /> path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: disallow overlapping input ranges for damon_set_regions()<br /> <br /> damon_set_regions() assumes the input ranges are sorted by the address and<br /> don&amp;#39;t overlap each other. Hence the assumption was initially to be<br /> explicitly validated. But commit 97d482f4592f ("mm/damon/sysfs: reuse<br /> damon_set_regions() for regions setting") has mistakenly removed the<br /> validation.<br /> <br /> This can make DAMON behave in unexpected ways. At the best, the<br /> monitoring results snapshot will just look weird since there will be<br /> overlapping regions. DAMOS will also work weirdly, applying the same<br /> action multiple times for overlapping regions, and make DAMOS quota weird.<br /> More seriously, depending on the setup and regions updates sequence,<br /> negative size regions can be made. It will trigger WARN_ONCE() if the<br /> kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the<br /> monitoring results, the negative size region can further trigger division<br /> by zero in damon_merge_two_regions().<br /> <br /> Note that some of the consequences including the WARN_ONCE() and the<br /> divide by zero depend on commits that were introduced after the root cause<br /> commit 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for<br /> regions setting").<br /> <br /> Fix the problems by checking the assumption and returning an error if<br /> the input ranges don&amp;#39;t meet the assumption.<br /> <br /> The issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: validate ranges in damon_set_regions()<br /> <br /> DAMON core logic assumes zero length regions don&amp;#39;t exist. However, a few<br /> DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT<br /> allow users to set empty monitoring target regions. This could result in<br /> WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and<br /> divide-by-zero from damon_merge_two_regions().<br /> <br /> For example, the WANR_ONCE() can be triggered like below.<br /> <br /> # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r)<br /> # CONFIG_DAMON_DEBUG_SANITY=y<br /> # damo start<br /> # cd /sys/kernel/mm/damon/admin/kdamonds/0<br /> # echo 0 &gt; contexts/0/targets/0/regions/0/start<br /> # echo 0 &gt; contexts/0/targets/0/regions/0/end<br /> # echo commit &gt; state<br /> # dmesg<br /> [....]<br /> [ 73.705780] ------------[ cut here ]------------<br /> [ 73.707552] start 0 &gt;= end 0<br /> [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758<br /> [...]<br /> <br /> All DAMON API callers eventually use damon_set_regions() to setup the<br /> regions. Add the validation logic in the function.

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 ]