Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/crypto: Fix wrong return code to engine in asynch callbacks<br /> <br /> When crypto_finalize_hash_request() or<br /> crypto_finalize_skcipher_request() explicitly completes a request, the<br /> do_one_request callback must return 0 to indicate successful<br /> handling. Returning a negative error code causes the crypto engine to<br /> assume the driver failed to take ownership and triggers a second<br /> completion via crypto_request_complete(), resulting in a double<br /> completion. This pattern occurs in paes_s390.c 4 times and once in<br /> phmac_s390.c.<br /> <br /> Fixed in phmac_do_one_request() and all four paes do_one_request<br /> callbacks (ecb, cbc, ctr, xts) by returning 0 after explicit<br /> finalization instead of propagating the error code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/crypto: Fix missing scrub of temp buffers with PAES algorithm<br /> <br /> In function ctr_paes_do_crypt() there is a buffer used to process<br /> remaining bytes

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engine<br /> <br /> When a request is transferred to the engine via<br /> crypto_transfer_hash_request_to_engine() there are two return codes<br /> signaling a successful transfer: EINPROGRESS and EBUSY. However the<br /> correct handling of EBUSY was missing and has been added as a return<br /> code indicating a successful transfer to the crypto engine.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm<br /> <br /> In function ctr_aes_crypt() there is a buffer used to process<br /> remaining bytes

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX<br /> <br /> When using a 5-level translation table via ZPCI_TABLE_TYPE_RFX<br /> get_rso_from_iova() returns NULL when the region-first entry is invalid.<br /> Yet in get_rto_from_iova() the region-second origin rso is not checked<br /> to be non-NULL before accessing rso[rsx] leading to a NULL pointer<br /> dereference instead of a NULL return when iova_to_phys() is called on<br /> a unmapped IOVA. Fix this by adding the missing NULL check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> landlock: Fix use-after-free of the source&amp;#39;s parent directory<br /> <br /> current_check_refer_path() reads old_dentry-&gt;d_parent without holding a<br /> reference nor a lock on it, and then dereferences it in<br /> collect_domain_accesses() and in the audit record.<br /> <br /> A reference on a child does not pin its parent: __d_move() reassigns<br /> dentry-&gt;d_parent and drops the reference the child held on its former<br /> parent. hook_path_rename() is not affected because the rename path<br /> calls lock_rename() before the hook, so the source cannot be reparented<br /> under it. hook_path_link() has no such protection: filename_linkat()<br /> holds a reference on the source dentry but neither locks nor references<br /> its parent, so a concurrent rename(2) can reparent the source while<br /> security_path_link() runs, and the former parent can then be removed and<br /> freed while the hook walks it.<br /> <br /> A process can trigger this after entering a Landlock domain that handles<br /> at least one filesystem access right. The process can then race a<br /> linkat(2) loop against rename(2) and rmdir(2):<br /> <br /> BUG: KASAN: slab-use-after-free in collect_domain_accesses+0x278/0x290<br /> Read of size 4 at addr ffff888160bd53f4 by task llrepro2/549<br /> collect_domain_accesses+0x278/0x290<br /> current_check_refer_path+0x952/0x1120<br /> security_path_link+0x1be/0x320<br /> filename_linkat+0x342/0x6d0<br /> __x64_sys_linkat+0xfa/0x150<br /> Freed by task 562:<br /> kmem_cache_free+0x139/0x4c0<br /> i_callback+0x4b/0x80<br /> rcu_core+0x7dc/0x10a0<br /> <br /> Take a reference on the dentry selected as the source parent, using<br /> dget() for the common-mount-root case and dget_parent() otherwise.<br /> Release it after the hierarchy walk and synchronous audit logging.<br /> <br /> [mic: Clarify the caller, reachability, and reference handling]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac802154: fix use-after-free of sdata via queued RX frames<br /> <br /> The RX softirq producer ieee802154_subif_frame() queues received beacon<br /> and MAC-command frames onto local-&gt;rx_beacon_list / rx_mac_cmd_list and<br /> schedules a process-context worker, storing a raw mac_pkt-&gt;sdata (and<br /> skb-&gt;dev == sdata-&gt;dev) with neither a reference nor any locking:<br /> <br /> - the lists have no lock: the softirq producer list_add_tail()s while the<br /> mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt<br /> the list;<br /> <br /> - the workers dereference the interface after it may have been freed.<br /> mac802154_rx_mac_cmd_worker() touches mac_pkt-&gt;sdata directly, and<br /> mac802154_rx_beacon_worker() -&gt; mac802154_process_beacon() dereferences<br /> skb-&gt;dev (== sdata-&gt;dev). Removing an interface frees its sdata<br /> (netdev_priv) while a queued frame still points at it, so a later worker<br /> run is a use-after-free.<br /> <br /> Reproduced under KASAN by flooding a victim interface with MAC command<br /> frames and removing it (the beacon path is the same class via skb-&gt;dev):<br /> <br /> BUG: KASAN: slab-use-after-free in mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154]<br /> Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31<br /> Workqueue: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154]<br /> Call Trace:<br /> mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154]<br /> process_one_work+0x611/0xe80<br /> worker_thread+0x52e/0xdc0<br /> kthread+0x30c/0x630<br /> ret_from_fork+0x2fd/0x3e0<br /> <br /> Fix both lists together:<br /> <br /> - add local-&gt;rx_lock and take it around every list access: the softirq<br /> producer (plain spin_lock, softirq context) and the workers and flush<br /> (spin_lock_bh, process context);<br /> <br /> - pin the interface for the lifetime of a queued frame with<br /> netdev_hold()/netdev_put(), so the worker can safely dereference sdata /<br /> skb-&gt;dev even while the interface is being removed;<br /> <br /> - dequeue under the lock at the head and loop-drain the whole list in the<br /> workers (they previously processed one frame per run and relied on a<br /> later enqueue to drain the rest);<br /> <br /> - drop not-yet-started frames of an interface before it is unregistered,<br /> from ieee802154_if_remove() (after the RCU grace period) and from the<br /> ieee802154_remove_interfaces() loop -- the latter is the whole-phy<br /> teardown path, which does not go through ieee802154_if_remove().<br /> <br /> An in-flight worker that already dequeued a frame keeps its own netdev<br /> reference; unregister_netdevice() then waits it out in netdev_run_todo(),<br /> which runs at rtnl_unlock() (rtnl released) and after the interface has<br /> been closed, so it does not pin rtnl. A worker blocked in an association<br /> TX only delays that one interface&amp;#39;s unregister (the usual "waiting for %s<br /> to become free"), it does not hold rtnl. netdev_hold() is used for this<br /> reason instead of a cancel_work_sync() under rtnl, which would block on<br /> the worker&amp;#39;s unbounded MLME TX wait via ieee802154_sync_queue().<br /> <br /> The mac-command worker additionally skips processing for a stopped<br /> interface (ieee802154_sdata_running()), avoiding a needless association<br /> response during teardown.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: reject invalid states in connection template sync records<br /> <br /> IPVS sync receivers validate protocol states before creating or updating a<br /> connection. For connection templates, however, they only log states outside<br /> the template state range and still store the value in the connection.<br /> <br /> A template can be returned by ordinary connection lookup. TCP and SCTP then<br /> use the invalid state as an index into their transition tables.<br /> <br /> Reject invalid template states in both sync protocol versions before<br /> looking up or modifying a connection. The version 1 path handles both<br /> IPv4 and IPv6 records.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (gpio-fan) Fix use-after-free in alarm work<br /> <br /> fan_alarm_irq_handler() queues fan_data-&gt;alarm_work, but nothing<br /> cancels it. fan_alarm_notify() dereferences fan_data and its hwmon<br /> device. On unbind, devres frees the interrupt, which only waits for<br /> the handler itself, and then releases the hwmon device and fan_data,<br /> so a pending fan_alarm_notify() can run after those frees.<br /> <br /> Replace INIT_WORK() with devm_work_autocancel(), registered before<br /> devm_request_irq(). The devres cleanup then frees the interrupt<br /> first, so no new work can be queued, and cancels the work while<br /> fan_data and the hwmon device are still alive.<br /> <br /> This issue was found by an in-house static analysis tool.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Clear stale peer app data after address list changes<br /> <br /> afs_fs_probe_fileserver() fetches the current endpoint state under<br /> server-&gt;fs_lock, but leaves old_alist as NULL. Consequently,<br /> afs_set_peer_appdata() treats every address list replacement as initial<br /> setup and only binds the new peers; it never unbinds peers removed from<br /> the old list.<br /> <br /> An address refresh can therefore proceed as follows. CPU 0 replaces<br /> server S&amp;#39;s list and drops Pold without clearing Pold-&gt;app_data. The<br /> server destroyer then clears only S&amp;#39;s current peers and lets S reach its<br /> RCU callback. After the callback frees S, CPU 1 handles a callback<br /> through an RxRPC connection that still pins Pold, reads Pold-&gt;app_data,<br /> and calls afs_use_server() on the freed object.<br /> <br /> KASAN reported:<br /> <br /> BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0<br /> Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74<br /> Call Trace:<br /> afs_find_server+0x3c/0xa0<br /> afs_rx_new_call+0x15c/0x390<br /> rxrpc_new_incoming_call+0x97c/0x1730<br /> rxrpc_input_packet.constprop.0+0xd03/0xec0<br /> rxrpc_io_thread+0x967/0x1640<br /> Allocated by task 93:<br /> afs_lookup_server+0x1a7/0x14c0<br /> afs_alloc_server_list+0x43f/0xb60<br /> afs_create_volume+0x923/0x1490<br /> afs_get_tree+0x1c6/0x10a0<br /> Freed by task 0:<br /> kfree+0x131/0x3c0<br /> rcu_core+0x50a/0x1850<br /> Last potentially related work creation:<br /> __call_rcu_common.constprop.0+0x71/0xa10<br /> afs_put_server+0x213/0x2b0<br /> <br /> Preserve old-&gt;addresses for the peer app-data update so that removed<br /> peers are cleared before the endpoint state is replaced. Also advance<br /> both cursors when the old and new lists share a peer; activating the<br /> old/new comparison without this would otherwise loop forever on the<br /> shared entry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix incorrect free in candidate cleanup in afs_lookup_server()<br /> <br /> Fix afs_lookup_server() to not free an existing server&amp;#39;s endpoint state<br /> when cleaning up a candidate server. The candidate record doesn&amp;#39;t have an<br /> endpoint state yet at this point, so the free for that can just be removed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix double-unmap of directory block<br /> <br /> Fix afs_edit_dir_remove() to use a cleanup function to unmap the block<br /> pointed to by afs_dir_iter::block if it&amp;#39;s left pointing to something rather<br /> than manually kunmapping the blocks. Manually kunmapping without clearing<br /> iter.blocks can result in a double-kunmap if afs_dir_find_block() is called<br /> twice in a row (which would be the case if the block being modified is not<br /> first in the hash chain).