Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: init run lock for extend inode<br /> <br /> After setting the inode mode of $Extend to a regular file, executing the<br /> truncate system call will enter the do_truncate() routine, causing the<br /> run_lock uninitialized error reported by syzbot.<br /> <br /> Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to<br /> a regular file, the do_truncate() routine would not be entered.<br /> <br /> Add the run_lock initialization when loading $Extend.<br /> <br /> syzbot reported:<br /> INFO: trying to register non-static key.<br /> Call Trace:<br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984<br /> register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299<br /> __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112<br /> lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868<br /> down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590<br /> ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860<br /> ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387<br /> ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: tmc: add the handle of the event to the path<br /> <br /> The handle is essential for retrieving the AUX_EVENT of each CPU and is<br /> required in perf mode. It has been added to the coresight_path so that<br /> dependent devices can access it from the path when needed.<br /> <br /> The existing bug can be reproduced with:<br /> perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null<br /> <br /> Showing an oops as follows:<br /> Unable to handle kernel paging request at virtual address 000f6e84934ed19e<br /> <br /> Call trace:<br /> tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P)<br /> catu_enable_hw+0xbc/0x3d0 [coresight_catu]<br /> catu_enable+0x70/0xe0 [coresight_catu]<br /> coresight_enable_path+0xb0/0x258 [coresight]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: smartpqi: Fix device resources accessed after device removal<br /> <br /> Correct possible race conditions during device removal.<br /> <br /> Previously, a scheduled work item to reset a LUN could still execute<br /> after the device was removed, leading to use-after-free and other<br /> resource access issues.<br /> <br /> This race condition occurs because the abort handler may schedule a LUN<br /> reset concurrently with device removal via sdev_destroy(), leading to<br /> use-after-free and improper access to freed resources.<br /> <br /> - Check in the device reset handler if the device is still present in<br /> the controller&amp;#39;s SCSI device list before running; if not, the reset<br /> is skipped.<br /> <br /> - Cancel any pending TMF work that has not started in sdev_destroy().<br /> <br /> - Ensure device freeing in sdev_destroy() is done while holding the<br /> LUN reset mutex to avoid races with ongoing resets.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: defer config put in recv_work<br /> <br /> There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and<br /> NBD_CMD_RECONFIGURE:<br /> nbd_genl_connect // conf_ref=2 (connect and recv_work A)<br /> nbd_open // conf_ref=3<br /> recv_work A done // conf_ref=2<br /> NBD_CLEAR_SOCK // conf_ref=1<br /> nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)<br /> close nbd // conf_ref=1<br /> recv_work B<br /> config_put // conf_ref=0<br /> atomic_dec(&amp;config-&gt;recv_threads); -&gt; UAF<br /> <br /> Or only running NBD_CLEAR_SOCK:<br /> nbd_genl_connect // conf_ref=2<br /> nbd_open // conf_ref=3<br /> NBD_CLEAR_SOCK // conf_ref=2<br /> close nbd<br /> nbd_release<br /> config_put // conf_ref=1<br /> recv_work<br /> config_put // conf_ref=0<br /> atomic_dec(&amp;config-&gt;recv_threads); -&gt; UAF<br /> <br /> Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the<br /> waiter") moved nbd_config_put() to run before waking up the waiter in<br /> recv_work, in order to ensure that nbd_start_device_ioctl() would not<br /> be woken up while nbd-&gt;task_recv was still uncleared.<br /> <br /> However, in nbd_start_device_ioctl(), after being woken up it explicitly<br /> calls flush_workqueue() to make sure all current works are finished.<br /> Therefore, there is no need to move the config put ahead of the wakeup.<br /> <br /> Move nbd_config_put() to the end of recv_work, so that the reference is<br /> held for the whole lifetime of the worker thread. This makes sure the<br /> config cannot be freed while recv_work is still running, even if clear<br /> + reconfigure interleave.<br /> <br /> In addition, we don&amp;#39;t need to worry about recv_work dropping the last<br /> nbd_put (which causes deadlock):<br /> <br /> path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):<br /> connect // nbd_refs=1 (trigger recv_work)<br /> open nbd // nbd_refs=2<br /> NBD_CLEAR_SOCK<br /> close nbd<br /> nbd_release<br /> nbd_disconnect_and_put<br /> flush_workqueue // recv_work done<br /> nbd_config_put<br /> nbd_put // nbd_refs=1<br /> nbd_put // nbd_refs=0<br /> queue_work<br /> <br /> path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):<br /> connect // nbd_refs=2 (trigger recv_work)<br /> open nbd // nbd_refs=3<br /> NBD_CLEAR_SOCK // conf_refs=2<br /> close nbd<br /> nbd_release<br /> nbd_config_put // conf_refs=1<br /> nbd_put // nbd_refs=2<br /> recv_work done // conf_refs=0, nbd_refs=1<br /> rmmod // nbd_refs=0<br /> <br /> Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: avoid repeated calls to del_gendisk<br /> <br /> There is a uaf problem which is found by case 23rdev-lifetime:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdead000000000122<br /> RIP: 0010:bdi_unregister+0x4b/0x170<br /> Call Trace:<br /> <br /> __del_gendisk+0x356/0x3e0<br /> mddev_unlock+0x351/0x360<br /> rdev_attr_store+0x217/0x280<br /> kernfs_fop_write_iter+0x14a/0x210<br /> vfs_write+0x29e/0x550<br /> ksys_write+0x74/0xf0<br /> do_syscall_64+0xbb/0x380<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ff5250a177e<br /> <br /> The sequence is:<br /> 1. rdev remove path gets reconfig_mutex<br /> 2. rdev remove path release reconfig_mutex in mddev_unlock<br /> 3. md stop calls do_md_stop and sets MD_DELETED<br /> 4. rdev remove path calls del_gendisk because MD_DELETED is set<br /> 5. md stop path release reconfig_mutex and calls del_gendisk again<br /> <br /> So there is a race condition we should resolve. This patch adds a<br /> flag MD_DO_DELETE to avoid the race condition.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix rcu protection in md_wakeup_thread<br /> <br /> We attempted to use RCU to protect the pointer &amp;#39;thread&amp;#39;, but directly<br /> passed the value when calling md_wakeup_thread(). This means that the<br /> RCU pointer has been acquired before rcu_read_lock(), which renders<br /> rcu_read_lock() ineffective and could lead to a use-after-free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix racy bitfield write in btrfs_clear_space_info_full()<br /> <br /> From the memory-barriers.txt document regarding memory barrier ordering<br /> guarantees:<br /> <br /> (*) These guarantees do not apply to bitfields, because compilers often<br /> generate code to modify these using non-atomic read-modify-write<br /> sequences. Do not attempt to use bitfields to synchronize parallel<br /> algorithms.<br /> <br /> (*) Even in cases where bitfields are protected by locks, all fields<br /> in a given bitfield must be protected by one lock. If two fields<br /> in a given bitfield are protected by different locks, the compiler&amp;#39;s<br /> non-atomic read-modify-write sequences can cause an update to one<br /> field to corrupt the value of an adjacent field.<br /> <br /> btrfs_space_info has a bitfield sharing an underlying word consisting of<br /> the fields full, chunk_alloc, and flush:<br /> <br /> struct btrfs_space_info {<br /> struct btrfs_fs_info * fs_info; /* 0 8 */<br /> struct btrfs_space_info * parent; /* 8 8 */<br /> ...<br /> int clamp; /* 172 4 */<br /> unsigned int full:1; /* 176: 0 4 */<br /> unsigned int chunk_alloc:1; /* 176: 1 4 */<br /> unsigned int flush:1; /* 176: 2 4 */<br /> ...<br /> <br /> Therefore, to be safe from parallel read-modify-writes losing a write to<br /> one of the bitfield members protected by a lock, all writes to all the<br /> bitfields must use the lock. They almost universally do, except for<br /> btrfs_clear_space_info_full() which iterates over the space_infos and<br /> writes out found-&gt;full = 0 without a lock.<br /> <br /> Imagine that we have one thread completing a transaction in which we<br /> finished deleting a block_group and are thus calling<br /> btrfs_clear_space_info_full() while simultaneously the data reclaim<br /> ticket infrastructure is running do_async_reclaim_data_space():<br /> <br /> T1 T2<br /> btrfs_commit_transaction<br /> btrfs_clear_space_info_full<br /> data_sinfo-&gt;full = 0<br /> READ: full:0, chunk_alloc:0, flush:1<br /> do_async_reclaim_data_space(data_sinfo)<br /> spin_lock(&amp;space_info-&gt;lock);<br /> if(list_empty(tickets))<br /> space_info-&gt;flush = 0;<br /> READ: full: 0, chunk_alloc:0, flush:1<br /> MOD/WRITE: full: 0, chunk_alloc:0, flush:0<br /> spin_unlock(&amp;space_info-&gt;lock);<br /> return;<br /> MOD/WRITE: full:0, chunk_alloc:0, flush:1<br /> <br /> and now data_sinfo-&gt;flush is 1 but the reclaim worker has exited. This<br /> breaks the invariant that flush is 0 iff there is no work queued or<br /> running. Once this invariant is violated, future allocations that go<br /> into __reserve_bytes() will add tickets to space_info-&gt;tickets but will<br /> see space_info-&gt;flush is set to 1 and not queue the work. After this,<br /> they will block forever on the resulting ticket, as it is now impossible<br /> to kick the worker again.<br /> <br /> I also confirmed by looking at the assembly of the affected kernel that<br /> it is doing RMW operations. For example, to set the flush (3rd) bit to 0,<br /> the assembly is:<br /> andb $0xfb,0x60(%rbx)<br /> and similarly for setting the full (1st) bit to 0:<br /> andb $0xfe,-0x20(%rax)<br /> <br /> So I think this is really a bug on practical systems. I have observed<br /> a number of systems in this exact state, but am currently unable to<br /> reproduce it.<br /> <br /> Rather than leaving this footgun lying around for the future, take<br /> advantage of the fact that there is room in the struct anyway, and that<br /> it is already quite large and simply change the three bitfield members to<br /> bools. This avoids writes to space_info-&gt;full having any effect on<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: allocate s_dio_done_wq for async reads as well<br /> <br /> Since commit 222f2c7c6d14 ("iomap: always run error completions in user<br /> context"), read error completions are deferred to s_dio_done_wq. This<br /> means the workqueue also needs to be allocated for async reads.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix double free of qgroup record after failure to add delayed ref head<br /> <br /> In the previous code it was possible to incur into a double kfree()<br /> scenario when calling add_delayed_ref_head(). This could happen if the<br /> record was reported to already exist in the<br /> btrfs_qgroup_trace_extent_nolock() call, but then there was an error<br /> later on add_delayed_ref_head(). In this case, since<br /> add_delayed_ref_head() returned an error, the caller went to free the<br /> record. Since add_delayed_ref_head() couldn&amp;#39;t set this kfree&amp;#39;d pointer<br /> to NULL, then kfree() would have acted on a non-NULL &amp;#39;record&amp;#39; object<br /> which was pointing to memory already freed by the callee.<br /> <br /> The problem comes from the fact that the responsibility to kfree the<br /> object is on both the caller and the callee at the same time. Hence, the<br /> fix for this is to shift the ownership of the &amp;#39;qrecord&amp;#39; object out of<br /> the add_delayed_ref_head(). That is, we will never attempt to kfree()<br /> the given object inside of this function, and will expect the caller to<br /> act on the &amp;#39;qrecord&amp;#39; object on its own. The only exception where the<br /> &amp;#39;qrecord&amp;#39; object cannot be kfree&amp;#39;d is if it was inserted into the<br /> tracing logic, for which we already have the &amp;#39;qrecord_inserted_ret&amp;#39;<br /> boolean to account for this. Hence, the caller has to kfree the object<br /> only if add_delayed_ref_head() reports not to have inserted it on the<br /> tracing logic.<br /> <br /> As a side-effect of the above, we must guarantee that<br /> &amp;#39;qrecord_inserted_ret&amp;#39; is properly initialized at the start of the<br /> function, not at the end, and then set when an actual insert<br /> happens. This way we avoid &amp;#39;qrecord_inserted_ret&amp;#39; having an invalid<br /> value on an early exit.<br /> <br /> The documentation from the add_delayed_ref_head() has also been updated<br /> to reflect on the exact ownership of the &amp;#39;qrecord&amp;#39; object.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks<br /> <br /> MT7996 driver can use both wed and wed_hif2 devices to offload traffic<br /> from/to the wireless NIC. In the current codebase we assume to always<br /> use the primary wed device in wed callbacks resulting in the following<br /> crash if the hw runs wed_hif2 (e.g. 6GHz link).<br /> <br /> [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a<br /> [ 297.464928] Mem abort info:<br /> [ 297.467722] ESR = 0x0000000096000005<br /> [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 297.476766] SET = 0, FnV = 0<br /> [ 297.479809] EA = 0, S1PTW = 0<br /> [ 297.482940] FSC = 0x05: level 1 translation fault<br /> [ 297.487809] Data abort info:<br /> [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000<br /> [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000<br /> [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP<br /> [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0<br /> [ 297.723908] Tainted: [O]=OOT_MODULE<br /> [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT)<br /> [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table]<br /> [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76]<br /> [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80<br /> [ 297.757126] sp : ffffffc080fe3ae0<br /> [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7<br /> [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00<br /> [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018<br /> [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000<br /> [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000<br /> [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da<br /> [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200<br /> [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002<br /> [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8<br /> [ 297.831686] Call trace:<br /> [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76]<br /> [ 297.839254] mtk_wed_flow_remove+0x58/0x80<br /> [ 297.843342] mtk_flow_offload_cmd+0x434/0x574<br /> [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40<br /> [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table]<br /> [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table]<br /> [ 297.864463] process_one_work+0x174/0x300<br /> [ 297.868465] worker_thread+0x278/0x430<br /> [ 297.872204] kthread+0xd8/0xdc<br /> [ 297.875251] ret_from_fork+0x10/0x20<br /> [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421)<br /> [ 297.884901] ---[ end trace 0000000000000000 ]---<br /> <br /> Fix the issue detecting the proper wed reference to use running wed<br /> callabacks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: limit the level of fs stacking for file-backed mounts<br /> <br /> Otherwise, it could cause potential kernel stack overflow (e.g., EROFS<br /> mounting itself).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()<br /> <br /> The rtl8187_rx_cb() calculates the rx descriptor header address<br /> by subtracting its size from the skb tail pointer.<br /> However, it does not validate if the received packet<br /> (skb-&gt;len from urb-&gt;actual_length) is large enough to contain this<br /> header.<br /> <br /> If a truncated packet is received, this will lead to a buffer<br /> underflow, reading memory before the start of the skb data area,<br /> and causing a kernel panic.<br /> <br /> Add length checks for both rtl8187 and rtl8187b descriptor headers<br /> before attempting to access them, dropping the packet cleanly if the<br /> check fails.