Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: ice_adapter: release xa entry on adapter allocation failure<br /> <br /> When ice_adapter_new() fails, the reserved XArray entry created by<br /> xa_insert() is not released. This causes subsequent insertions at<br /> the same index to return -EBUSY, potentially leading to<br /> NULL pointer dereferences.<br /> <br /> Reorder the operations as suggested by Przemek Kitszel:<br /> 1. Check if adapter already exists (xa_load)<br /> 2. Reserve the XArray slot (xa_reserve)<br /> 3. Allocate the adapter (ice_adapter_new)<br /> 4. Store the adapter (xa_store)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Don&amp;#39;t call reqsk_fastopen_remove() in tcp_conn_request().<br /> <br /> syzbot reported the splat below in tcp_conn_request(). [0]<br /> <br /> If a listener is close()d while a TFO socket is being processed in<br /> tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk-&gt;sk<br /> and calls inet_child_forget(), which calls tcp_disconnect() for the<br /> TFO socket.<br /> <br /> After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(),<br /> where reqsk_put() is called due to !reqsk-&gt;sk.<br /> <br /> Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the<br /> last req-&gt;rsk_refcnt and frees reqsk, and __reqsk_free() at the<br /> drop_and_free label causes the refcount underflow for the listener<br /> and double-free of the reqsk.<br /> <br /> Let&amp;#39;s remove reqsk_fastopen_remove() in tcp_conn_request().<br /> <br /> Note that other callers make sure tp-&gt;fastopen_rsk is not NULL.<br /> <br /> [0]:<br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28)<br /> Modules linked in:<br /> CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> RIP: 0010:refcount_warn_saturate (lib/refcount.c:28)<br /> Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6<br /> RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246<br /> RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900<br /> RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280<br /> RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280<br /> R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100<br /> R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8<br /> FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0<br /> Call Trace:<br /> <br /> tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301)<br /> tcp_rcv_state_process (net/ipv4/tcp_input.c:6708)<br /> tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670)<br /> tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906)<br /> ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438)<br /> ip6_input (net/ipv6/ip6_input.c:500)<br /> ipv6_rcv (net/ipv6/ip6_input.c:311)<br /> __netif_receive_skb (net/core/dev.c:6104)<br /> process_backlog (net/core/dev.c:6456)<br /> __napi_poll (net/core/dev.c:7506)<br /> net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696)<br /> handle_softirqs (kernel/softirq.c:579)<br /> do_softirq (kernel/softirq.c:480)<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()<br /> <br /> If new_asoc-&gt;peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0<br /> and sctp_ulpevent_make_authkey() returns 0, then the variable<br /> ai_ev remains zero and the zero will be dereferenced<br /> in the sctp_ulpevent_free() function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pwm: berlin: Fix wrong register in suspend/resume<br /> <br /> The &amp;#39;enable&amp;#39; register should be BERLIN_PWM_EN rather than<br /> BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there<br /> will be cpu exception then kernel panic during suspend/resume.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: lan78xx: Fix lost EEPROM read timeout error(-ETIMEDOUT) in lan78xx_read_raw_eeprom<br /> <br /> Syzbot reported read of uninitialized variable BUG with following call stack.<br /> <br /> lan78xx 8-1:1.0 (unnamed net_device) (uninitialized): EEPROM read operation timeout<br /> =====================================================<br /> BUG: KMSAN: uninit-value in lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline]<br /> BUG: KMSAN: uninit-value in lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]<br /> BUG: KMSAN: uninit-value in lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241<br /> lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline]<br /> lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]<br /> lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241<br /> lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766<br /> lan78xx_probe+0x225c/0x3310 drivers/net/usb/lan78xx.c:4707<br /> <br /> Local variable sig.i.i created at:<br /> lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1092 [inline]<br /> lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]<br /> lan78xx_reset+0x77e/0x2cd0 drivers/net/usb/lan78xx.c:3241<br /> lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766<br /> <br /> The function lan78xx_read_raw_eeprom failed to properly propagate EEPROM<br /> read timeout errors (-ETIMEDOUT). In the fallthrough path, it first<br /> attempted to restore the pin configuration for LED outputs and then<br /> returned only the status of that restore operation, discarding the<br /> original timeout error.<br /> <br /> As a result, callers could mistakenly treat the data buffer as valid<br /> even though the EEPROM read had actually timed out with no data or partial<br /> data.<br /> <br /> To fix this, handle errors in restoring the LED pin configuration separately.<br /> If the restore succeeds, return any prior EEPROM timeout error correctly<br /> to the caller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: guard against EA inode refcount underflow in xattr update<br /> <br /> syzkaller found a path where ext4_xattr_inode_update_ref() reads an EA<br /> inode refcount that is already

*** Pendiente de traducción *** IBM QRadar SIEM 7.5 through 7.5.0 UP14 stores user credentials in configuration files in source control which can be read by an authenticated user.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pid: Add a judgment for ns null in pid_nr_ns<br /> <br /> __task_pid_nr_ns<br /> ns = task_active_pid_ns(current);<br /> pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);<br /> if (pid &amp;&amp; ns-&gt;level level) {<br /> <br /> Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.<br /> <br /> For example:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058<br /> Mem abort info:<br /> ESR = 0x0000000096000007<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x07: level 3 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000<br /> [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000<br /> pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : __task_pid_nr_ns+0x74/0xd0<br /> lr : __task_pid_nr_ns+0x24/0xd0<br /> sp : ffffffc08001bd10<br /> x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001<br /> x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31<br /> x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0<br /> x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000<br /> x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc<br /> x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800<br /> x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001<br /> x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449<br /> x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc<br /> x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0<br /> Call trace:<br /> __task_pid_nr_ns+0x74/0xd0<br /> ...<br /> __handle_irq_event_percpu+0xd4/0x284<br /> handle_irq_event+0x48/0xb0<br /> handle_fasteoi_irq+0x160/0x2d8<br /> generic_handle_domain_irq+0x44/0x60<br /> gic_handle_irq+0x4c/0x114<br /> call_on_irq_stack+0x3c/0x74<br /> do_interrupt_handler+0x4c/0x84<br /> el1_interrupt+0x34/0x58<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x68/0x6c<br /> account_kernel_stack+0x60/0x144<br /> exit_task_stack_account+0x1c/0x80<br /> do_exit+0x7e4/0xaf8<br /> ...<br /> get_signal+0x7bc/0x8d8<br /> do_notify_resume+0x128/0x828<br /> el0_svc+0x6c/0x70<br /> el0t_64_sync_handler+0x68/0xbc<br /> el0t_64_sync+0x1a8/0x1ac<br /> Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: verify orphan file size is not too big<br /> <br /> In principle orphan file can be arbitrarily large. However orphan replay<br /> needs to traverse it all and we also pin all its buffers in memory. Thus<br /> filesystems with absurdly large orphan files can lead to big amounts of<br /> memory consumed. Limit orphan file size to a sane value and also use<br /> kvmalloc() for allocating array of block descriptor structures to avoid<br /> large order allocations for sane but large orphan files.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop<br /> <br /> The cleanup loop was starting at the wrong array index, causing<br /> out-of-bounds access.<br /> Start the loop at the correct index for zero-indexed arrays to prevent<br /> accessing memory beyond the allocated array bounds.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP<br /> <br /> When running as an SNP or TDX guest under KVM, force the legacy PCI hole,<br /> i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC<br /> via a forced variable MTRR range.<br /> <br /> In most KVM-based setups, legacy devices such as the HPET and TPM are<br /> enumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, and<br /> optionally a SystemMemory descriptor for an OperationRegion, e.g. if the<br /> device needs to be accessed via a Control Method.<br /> <br /> If a SystemMemory entry is present, then the kernel&amp;#39;s ACPI driver will<br /> auto-ioremap the region so that it can be accessed at will. However, the<br /> ACPI spec doesn&amp;#39;t provide a way to enumerate the memory type of<br /> SystemMemory regions, i.e. there&amp;#39;s no way to tell software that a region<br /> must be mapped as UC vs. WB, etc. As a result, Linux&amp;#39;s ACPI driver always<br /> maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.<br /> <br /> The dedicated device drivers however, e.g. the HPET driver and TPM driver,<br /> want to map their associated memory as UC or WC, as accessing PCI devices<br /> using WB is unsupported.<br /> <br /> On bare metal and non-CoCO, the conflicting requirements "work" as firmware<br /> configures the PCI hole (and other device memory) to be UC in the MTRRs.<br /> So even though the ACPI mappings request WB, they are forced to UC- in the<br /> kernel&amp;#39;s tracking due to the kernel properly handling the MTRR overrides,<br /> and thus are compatible with the drivers&amp;#39; requested WC/UC-.<br /> <br /> With force WB MTRRs on SNP and TDX guests, the ACPI mappings get their<br /> requested WB if the ACPI mappings are established before the dedicated<br /> driver code attempts to initialize the device. E.g. if acpi_init()<br /> runs before the corresponding device driver is probed, ACPI&amp;#39;s WB mapping<br /> will "win", and result in the driver&amp;#39;s ioremap() failing because the<br /> existing WB mapping isn&amp;#39;t compatible with the requested WC/UC-.<br /> <br /> E.g. when a TPM is emulated by the hypervisor (ignoring the security<br /> implications of relying on what is allegedly an untrusted entity to store<br /> measurements), the TPM driver will request UC and fail:<br /> <br /> [ 1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0<br /> [ 1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12<br /> <br /> Note, the &amp;#39;0x2&amp;#39; and &amp;#39;0x0&amp;#39; values refer to "enum page_cache_mode", not x86&amp;#39;s<br /> memtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).<br /> E.g. tracing mapping requests for TPM TIS yields:<br /> <br /> Mapping TPM TIS with req_type = 0<br /> WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460<br /> Modules linked in:<br /> CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY<br /> Tainted: [W]=WARN<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025<br /> RIP: 0010:memtype_reserve+0x2ab/0x460<br /> __ioremap_caller+0x16d/0x3d0<br /> ioremap_cache+0x17/0x30<br /> x86_acpi_os_ioremap+0xe/0x20<br /> acpi_os_map_iomem+0x1f3/0x240<br /> acpi_os_map_memory+0xe/0x20<br /> acpi_ex_system_memory_space_handler+0x273/0x440<br /> acpi_ev_address_space_dispatch+0x176/0x4c0<br /> acpi_ex_access_region+0x2ad/0x530<br /> acpi_ex_field_datum_io+0xa2/0x4f0<br /> acpi_ex_extract_from_field+0x296/0x3e0<br /> acpi_ex_read_data_from_field+0xd1/0x460<br /> acpi_ex_resolve_node_to_value+0x2ee/0x530<br /> acpi_ex_resolve_to_value+0x1f2/0x540<br /> acpi_ds_evaluate_name_path+0x11b/0x190<br /> acpi_ds_exec_end_op+0x456/0x960<br /> acpi_ps_parse_loop+0x27a/0xa50<br /> acpi_ps_parse_aml+0x226/0x600<br /> acpi_ps_execute_method+0x172/0x3e0<br /> acpi_ns_evaluate+0x175/0x5f0<br /> acpi_evaluate_object+0x213/0x490<br /> acpi_evaluate_integer+0x6d/0x140<br /> acpi_bus_get_status+0x93/0x150<br /> acpi_add_single_object+0x43a/0x7c0<br /> acpi_bus_check_add+0x149/0x3a0<br /> acpi_bus_check_add_1+0x16/0x30<br /> acpi_ns_walk_namespace+0x22c/0x360<br /> acpi_walk_namespace+0x15c/0x170<br /> acpi_bus_scan+0x1dd/0x200<br /> acpi_scan_init+0xe5/0x2b0<br /> acpi_init+0x264/0x5b0<br /> do_one_i<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: skcipher - Fix reqsize handling<br /> <br /> Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg")<br /> introduced cra_reqsize field in crypto_alg struct to replace type<br /> specific reqsize fields. It looks like this was introduced specifically<br /> for ahash and acomp from the commit description as subsequent commits<br /> add necessary changes in these alg frameworks.<br /> <br /> However, this is being recommended for use in all crypto algs [1]<br /> instead of setting reqsize using crypto_*_set_reqsize(). Using<br /> cra_reqsize in skcipher algorithms, hence, causes memory<br /> corruptions and crashes as the underlying functions in the algorithm<br /> framework have not been updated to set the reqsize properly from<br /> cra_reqsize. [2]<br /> <br /> Add proper set_reqsize calls in the skcipher init function to<br /> properly initialize reqsize for these algorithms in the framework.<br /> <br /> [1]: https://lore.kernel.org/linux-crypto/aCL8BxpHr5OpT04k@gondor.apana.org.au/<br /> [2]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b