Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Avoid NULL pointer dereference or refcount corruption<br /> <br /> Commit 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE")<br /> fixed a NULL pointer dereference in an unlikely situation partly.<br /> <br /> If dev_pasid is not found in the dev_pasids list, it remains NULL.<br /> However, the teardown operations are executed unconditionally, this lead<br /> to a NULL pointer dereference or refcount corruption.<br /> <br /> If the domain was never attached to this IOMMU, info will be NULL, which<br /> would cause an immediate dereference when checking --info-&gt;refcnt.<br /> <br /> Even if info is not NULL, decrementing the refcount without having removed<br /> a valid PASID might unbalance the count. This could lead to premature<br /> dropping of the refcount to 0, potentially causing a use-after-free for the<br /> remaining active devices sharing the domain.<br /> <br /> Fix it by returning early if dev_pasid is NULL, before executing the<br /> teardown operations.<br /> <br /> Issue found by AI review and suggested by Kevin Tian.<br /> https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com

*** Pendiente de traducción *** OpenProject is open-source, web-based project management software. Prior to 17.3.3 and 17.4.1, cache store poisoning leads to Remote Code Execution (RCE). This vulnerability is fixed in 17.3.3 and 17.4.1.

*** Pendiente de traducción *** OpenProject is open-source, web-based project management software. Prior to 17.3.3 and 17.4.1, there is a CSRF on TARGET through /users/:id via POST parameter "user[admin]". This vulnerability is fixed in 17.3.3 and 17.4.1.

*** Pendiente de traducción *** OpenProject is open-source, web-based project management software. Prior to 17.3.3 and 17.4.1, the HTML sanitizer grants elements unrestricted data-* attributes via :data wildcard. An attacker injects data-controller="poll-for-changes" into a work package description, causing Stimulus.js to mount a controller that fetches an attacker-uploaded attachment and passes it to renderStreamMessage(). This executes arbitrary Turbo Stream actions — including redirect_to — in every victim&amp;#39;s authenticated browser session, redirecting them to an attacker-controlled server. This vulnerability is fixed in 17.3.3 and 17.4.1.

*** Pendiente de traducción *** OpenProject is open-source, web-based project management software. Prior to 17.3.3 and 17.4.1, there is an IDOR through /projects//settings/project_storages/ via PATCH parameter "storages_project_storage[project_folder_id]" leads to Access to Unauthorized Resources. A project-admin in one project can hijack the managed Nextcloud or OneDrive folder of another project on the same storage by writing the victim project&amp;#39;s project_folder_id into the attacker&amp;#39;s Storages::ProjectStorage row. The next managed-folder sync overwrites the ACL on the referenced folder with the attacker project&amp;#39;s user list. This vulnerability is fixed in 17.3.3 and 17.4.1.

*** Pendiente de traducción *** OpenProject is open-source, web-based project management software. Prior to 17.3.3 and 17.4.1, OpenProject&amp;#39;s Storages module writes the OneDrive/SharePoint userless OAuth access_token plaintext to Rails.cache under the deterministic key storage..httpx_access_token, repopulated continuously by an hourly cron and every userless-OAuth call site (see Write cadence). None of the three allowed cache backends (file_store, memcache, redis) encrypts at rest. An attacker with read access to the cache backend recovers the Azure-AD application-tier bearer with an anonymous get over the memcached binary protocol (or the equivalent against Redis). This vulnerability is fixed in 17.3.3 and 17.4.1.