Vulnerabilities

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)

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 />

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.

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.

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.

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

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.

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

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.

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.

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---

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