Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: fix incorrect inheritable capability in CAPSET records<br /> <br /> __audit_log_capset() records the effective capability set into the<br /> inheritable field due to a copy-paste error. Every CAPSET audit<br /> record therefore reports cap_pi (process inheritable) with the value<br /> of cap_effective instead of cap_inheritable.<br /> <br /> This silently corrupts audit data used for compliance and forensic<br /> analysis: an attacker who modifies inheritable capabilities to<br /> prepare for a privilege-escalating exec would have the change masked<br /> in the audit trail.<br /> <br /> The bug has been present since the original introduction of CAPSET<br /> audit records in 2008.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: Reserve an extra page for early kernel mapping<br /> <br /> The final part of [data, end) segment may overflow into the next page of<br /> init_pg_end[1] which is the gap page before early_init_stack[2]:<br /> <br /> [1]<br /> crash_arm64_v9.0.1&gt; vtop ffffffed00601000<br /> VIRTUAL PHYSICAL<br /> ffffffed00601000 83401000<br /> <br /> PAGE DIRECTORY: ffffffecffd62000<br /> PGD: ffffffecffd62da0 =&gt; 10000000833fb003<br /> PMD: ffffff80033fb018 =&gt; 10000000833fe003<br /> PTE: ffffff80033fe008 =&gt; 68000083401f03<br /> PAGE: 83401000<br /> <br /> PTE PHYSICAL FLAGS<br /> 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)<br /> <br /> PAGE PHYSICAL MAPPING INDEX CNT FLAGS<br /> fffffffec00d0040 83401000 0 0 1 4000 reserved<br /> <br /> [2]<br /> ffffffed002c8000 (r) __pi__data<br /> ffffffed0054e000 (d) __pi___bss_start<br /> ffffffed005f5000 (b) __pi_init_pg_dir<br /> ffffffed005fe000 (b) __pi_init_pg_end<br /> ffffffed005ff000 (B) early_init_stack<br /> ffffffed00608000 (b) __pi__end<br /> <br /> For 4K pages, the early kernel mapping may use 2MB block entries but the<br /> kernel segments are only 64KB aligned. Segment boundaries that fall<br /> within a 2MB block therefore require a PTE table so that different<br /> attributes can be applied on either side of the boundary.<br /> <br /> KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel<br /> VMAs registered by declare_kernel_vmas(). However, since commit<br /> 5973a62efa34 ("arm64: map [_text, _stext) virtual address range<br /> non-executable+read-only"), the early mapper also maps [_text, _stext)<br /> separately from [_stext, _etext). This adds one more early-only split<br /> and can require one more page-table page than the existing<br /> EARLY_SEGMENT_EXTRA_PAGES allowance reserves.<br /> <br /> Increase the 4K-page early mapping allowance by one page to cover that<br /> additional split.<br /> <br /> [catalin.marinas@arm.com: rewrote part of the commit log]<br /> [catalin.marinas@arm.com: expanded the code comment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL pointer dereference in ice_reset_all_vfs()<br /> <br /> ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi().<br /> When the VSI rebuild fails (e.g. during NVM firmware update via<br /> nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path,<br /> leaving txq_map and rxq_map as NULL. The subsequent unconditional call<br /> to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in<br /> ice_ena_vf_q_mappings() when it accesses vsi-&gt;txq_map[0].<br /> <br /> The single-VF reset path in ice_reset_vf() already handles this<br /> correctly by checking the return value of ice_vf_reconfig_vsi() and<br /> skipping ice_vf_post_vsi_rebuild() on failure.<br /> <br /> Apply the same pattern to ice_reset_all_vfs(): check the return value<br /> of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and<br /> ice_eswitch_attach_vf() on failure. The VF is left safely disabled<br /> (ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can<br /> be recovered via a VFLR triggered by a PCI reset of the VF<br /> (sysfs reset or driver rebind).<br /> <br /> Note that this patch does not prevent the VF VSI rebuild from failing<br /> during NVM update — the underlying cause is firmware being in a<br /> transitional state while the EMP reset is processed, which can cause<br /> Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This<br /> patch only prevents the subsequent NULL pointer dereference that<br /> crashes the kernel when the rebuild does fail.<br /> <br /> crash&gt; bt<br /> PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5"<br /> #0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee<br /> #1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba<br /> #2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540<br /> #3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda<br /> #4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997<br /> #5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595<br /> #6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2<br /> [exception RIP: ice_ena_vf_q_mappings+0x79]<br /> RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206<br /> RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000<br /> RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040<br /> R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000<br /> R13: 0000000000000010 R14: R15:<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice]<br /> #8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice]<br /> #9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice]<br /> #10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4<br /> #11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de<br /> #12 [ff72159bcfe5bf18] kthread at ffffffffaa946663<br /> #13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9<br /> <br /> The panic occurs attempting to dereference the NULL pointer in RDX at<br /> ice_sriov.c:294, which loads vsi-&gt;txq_map (offset 0x4b8 in ice_vsi).<br /> <br /> The faulting VSI is an allocated slab object but not fully initialized<br /> after a failed ice_vsi_rebuild():<br /> <br /> crash&gt; struct ice_vsi 0xff34c9efc27d4828<br /> netdev = 0x0,<br /> rx_rings = 0x0,<br /> tx_rings = 0x0,<br /> q_vectors = 0x0,<br /> txq_map = 0x0,<br /> rxq_map = 0x0,<br /> alloc_txq = 0x10,<br /> num_txq = 0x10,<br /> alloc_rxq = 0x10,<br /> num_rxq = 0x10,<br /> <br /> The nvmupdate64e process was performing NVM firmware update:<br /> <br /> crash&gt; bt 0xff34c9edd1a30000<br /> PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e"<br /> #0 [ff72159bcd617618] __schedule at ffffffffab5333f8<br /> #4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice]<br /> #5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice]<br /> #6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice]<br /> #7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice]<br /> #8 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/eustall: Fix drm_dev_put called before stream disable in close<br /> <br /> In xe_eu_stall_stream_close(), drm_dev_put() is called before the<br /> stream is disabled and its resources are freed. If this drops the<br /> last reference, the device structures could be freed while the<br /> subsequent cleanup code still accesses them, leading to a<br /> use-after-free.<br /> <br /> Fix this by moving drm_dev_put() after all device accesses are<br /> complete. This matches the ordering in xe_oa_release().<br /> <br /> (cherry picked from commit 35aff528f7297e949e5e19c9cd7fd748cf1cf21c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda/conexant: Fix missing error check for jack detection<br /> <br /> In cx_probe(), the return value of snd_hda_jack_detect_enable_callback()<br /> is ignored. This function returns a pointer, and if it fails (e.g., due<br /> to memory allocation failure), it returns an error pointer which must<br /> be checked using IS_ERR().<br /> <br /> If the registration fails, the driver continues to probe, but the jack<br /> detection callback will not be registered. This can lead to a kernel<br /> crash later when the driver attempts to handle jack events or accesses<br /> the uninitialized structure.<br /> <br /> Check the return value using IS_ERR() and propagate the error via<br /> PTR_ERR() to the probe caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kexec: Push kjump return address even for non-kjump kexec<br /> <br /> The version of purgatory code shipped by kexec-tools attempts to look above<br /> the top of its stack to find a return address for a kjump, even in a non-kjump<br /> kexec.<br /> <br /> After the commit in Fixes: the word above the stack might not be there,<br /> leading to a fault (which is at least now caught by my exception-handling code<br /> in kexec).<br /> <br /> That commit fixed things for the actual kjump path, but no longer<br /> "gratuitously" pushes the unused return address to the stack in the non-kjump<br /> path. Put that *back* in the non-kjump path, to prevent purgatory from<br /> crashing when trying to access it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Bounds-check devid in __rlookup_amd_iommu()<br /> <br /> iommu_device_register() walks every device on the PCI bus via<br /> bus_for_each_dev() and calls amd_iommu_probe_device() for each. The<br /> inlined check_device() path computes the device&amp;#39;s sbdf, calls<br /> rlookup_amd_iommu() to find the owning IOMMU, and only afterwards<br /> verifies devid last_bdf. __rlookup_amd_iommu() indexes<br /> rlookup_table[devid] with no bounds check of its own, so for a PCI<br /> device whose BDF is not described by the IVRS, the lookup reads past<br /> the end of the allocation before the caller&amp;#39;s bounds check can run.<br /> <br /> This was harmless before commit e874c666b15b ("iommu/amd: Change<br /> rlookup, irq_lookup, and alias to use kvalloc()"): the table was a<br /> zeroed page-order allocation, so the over-read returned NULL and the<br /> caller&amp;#39;s NULL check skipped the device. After that commit the table is<br /> a tight kvcalloc() and the over-read returns adjacent slab contents,<br /> which check_device() then dereferences as a struct amd_iommu *,<br /> causing a boot-time GPF.<br /> <br /> Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS<br /> describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at<br /> 00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation,<br /> into the adjacent kmalloc-512 slab object:<br /> <br /> pci 0000:00:04.0: Adding to iommu group 0<br /> pci 0000:00:05.0: Adding to iommu group 1<br /> pci 0000:00:06.0: Adding to iommu group 2<br /> pci 0000:00:07.0: Adding to iommu group 3<br /> Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025<br /> RIP: 0010:amd_iommu_probe_device+0x54/0x3a0<br /> Call Trace:<br /> __iommu_probe_device+0x107/0x520<br /> probe_iommu_group+0x29/0x50<br /> bus_for_each_dev+0x7e/0xe0<br /> iommu_device_register+0xc9/0x240<br /> iommu_go_to_state+0x9c0/0x1c60<br /> amd_iommu_init+0x14/0x40<br /> pci_iommu_init+0x16/0x60<br /> do_one_initcall+0x47/0x2f0<br /> <br /> Guard the array access in __rlookup_amd_iommu(). With the fix applied<br /> on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: only release the dirty pages io tree after successful writes<br /> <br /> [WARNING]<br /> With extra warning on dirty extent buffers at umount (aka, the next<br /> patch in the series), test case generic/388 can trigger the following<br /> warning about dirty extent buffers at unmount time:<br /> <br /> BTRFS critical (device dm-2 state E): emergency shutdown<br /> BTRFS error (device dm-2 state E): error while writing out transaction: -30<br /> BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction.<br /> BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30)<br /> BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem<br /> BTRFS info (device dm-2 state EA): forced readonly<br /> BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c<br /> ------------[ cut here ]------------<br /> WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368<br /> CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G OE 7.1.0-rc1-custom+ #372 PREEMPT(full) 2de38db8d1deae71fde295430a0ff3ab98ccf596<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022<br /> RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs]<br /> Call Trace:<br /> <br /> close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]<br /> generic_shutdown_super+0x89/0x1a0<br /> kill_anon_super+0x16/0x40<br /> btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]<br /> deactivate_locked_super+0x2d/0xb0<br /> cleanup_mnt+0xdc/0x140<br /> task_work_run+0x5a/0xa0<br /> exit_to_user_mode_loop+0x123/0x4b0<br /> do_syscall_64+0x243/0x7c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7<br /> BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7<br /> BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7<br /> BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7<br /> BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7<br /> BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7<br /> BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7<br /> BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7<br /> <br /> I&amp;#39;m using a stripped down version, which seems to trigger the warning<br /> more reliably:<br /> <br /> _fsstress_pid=""<br /> workload()<br /> {<br /> dmesg -C<br /> mkfs.btrfs -f -K $dev &gt; /dev/null<br /> echo 1 &gt; /sys/kernel/debug/clear_warn_once<br /> mount $dev $mnt<br /> $fsstress -w -n 1024 -p 4 -d $mnt &amp;<br /> _fsstress_pid=$!<br /> sleep 0<br /> $godown $mnt<br /> pkill --echo -PIPE fsstress &gt; /dev/null<br /> wait $_fsstress_pid<br /> unset _fsstress_pid<br /> umount $mnt<br /> <br /> if dmesg | grep -q "WARNING"; then<br /> fail<br /> fi<br /> }<br /> <br /> for (( i = 0; i

OpenProject is open-source, web-based project management software. Prior to 17.3.3 and 17.4.1, there is a SQL injection in timestamps functionality. OpenProject baseline comparison allows callers to request historic work-package attributes using the timestamps parameter. This vulnerability is fixed in 17.3.3 and 17.4.1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm_mpam: Check whether the config array is allocated before destroying it<br /> <br /> __destroy_component_cfg() is called to free the configuration array.<br /> It uses the embedded &amp;#39;garbage&amp;#39; structure, which means the array has<br /> to be allocated.<br /> <br /> If __destroy_component_cfg() is called from mpam_disable() before the<br /> configuration was ever allocated, then a NULL pointer is dereferenced.<br /> <br /> Check for this case and return early if the configuration is not<br /> allocated.<br /> <br /> __destroy_component_cfg() also frees the mbwu_state as this is allocated<br /> by __allocate_component_cfg(). As the mbwu_state is allocated after<br /> comp-&gt;cfg is set, and is also under mpam_list_lock, only the first<br /> pointer needs checking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gma500/oaktrail_lvds: fix hang on init failure<br /> <br /> The LVDS init code looks up an I2C adapter using i2c_get_adapter() and<br /> tries to read the EDID before falling back to allocating and registering<br /> its own adapter.<br /> <br /> The error handling does not separate these cases so on a late init<br /> failure it will try to deregister and free also an adapter that had<br /> previously been registered. Since i2c_get_adapter() takes another<br /> reference to the adapter, deregistration hangs indefinitely while<br /> waiting for the reference to be released.<br /> <br /> Fix this by only destroying adapters allocated during LVDS init on<br /> errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Fix NULL group-&gt;domain dereference in pci_dev_reset_iommu_done()<br /> <br /> Local sashiko review pointed it out that group-&gt;domain could be NULL when<br /> a default domain fails to allocate during the first probe, which can crash<br /> at domain-&gt;ops-&gt;attach_dev dereference in __iommu_attach_device() invoked<br /> by pci_dev_reset_iommu_done().<br /> <br /> pci_dev_reset_iommu_prepare() is fine as an old_domain pointer can be NULL.<br /> <br /> Skip the re-attach in pci_dev_reset_iommu_done() to fix the bug.