Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix WARN_ON in iommu probe path<br /> <br /> Commit 1a75cc710b95 ("iommu/vt-d: Use rbtree to track iommu probed<br /> devices") adds all devices probed by the iommu driver in a rbtree<br /> indexed by the source ID of each device. It assumes that each device<br /> has a unique source ID. This assumption is incorrect and the VT-d<br /> spec doesn&amp;#39;t state this requirement either.<br /> <br /> The reason for using a rbtree to track devices is to look up the device<br /> with PCI bus and devfunc in the paths of handling ATS invalidation time<br /> out error and the PRI I/O page faults. Both are PCI ATS feature related.<br /> <br /> Only track the devices that have PCI ATS capabilities in the rbtree to<br /> avoid unnecessary WARN_ON in the iommu probe path. Otherwise, on some<br /> platforms below kernel splat will be displayed and the iommu probe results<br /> in failure.<br /> <br /> WARNING: CPU: 3 PID: 166 at drivers/iommu/intel/iommu.c:158 intel_iommu_probe_device+0x319/0xd90<br /> Call Trace:<br /> <br /> ? __warn+0x7e/0x180<br /> ? intel_iommu_probe_device+0x319/0xd90<br /> ? report_bug+0x1f8/0x200<br /> ? handle_bug+0x3c/0x70<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? intel_iommu_probe_device+0x319/0xd90<br /> ? debug_mutex_init+0x37/0x50<br /> __iommu_probe_device+0xf2/0x4f0<br /> iommu_probe_device+0x22/0x70<br /> iommu_bus_notifier+0x1e/0x40<br /> notifier_call_chain+0x46/0x150<br /> blocking_notifier_call_chain+0x42/0x60<br /> bus_notify+0x2f/0x50<br /> device_add+0x5ed/0x7e0<br /> platform_device_add+0xf5/0x240<br /> mfd_add_devices+0x3f9/0x500<br /> ? preempt_count_add+0x4c/0xa0<br /> ? up_write+0xa2/0x1b0<br /> ? __debugfs_create_file+0xe3/0x150<br /> intel_lpss_probe+0x49f/0x5b0<br /> ? pci_conf1_write+0xa3/0xf0<br /> intel_lpss_pci_probe+0xcf/0x110 [intel_lpss_pci]<br /> pci_device_probe+0x95/0x120<br /> really_probe+0xd9/0x370<br /> ? __pfx___driver_attach+0x10/0x10<br /> __driver_probe_device+0x73/0x150<br /> driver_probe_device+0x19/0xa0<br /> __driver_attach+0xb6/0x180<br /> ? __pfx___driver_attach+0x10/0x10<br /> bus_for_each_dev+0x77/0xd0<br /> bus_add_driver+0x114/0x210<br /> driver_register+0x5b/0x110<br /> ? __pfx_intel_lpss_pci_driver_init+0x10/0x10 [intel_lpss_pci]<br /> do_one_initcall+0x57/0x2b0<br /> ? kmalloc_trace+0x21e/0x280<br /> ? do_init_module+0x1e/0x210<br /> do_init_module+0x5f/0x210<br /> load_module+0x1d37/0x1fc0<br /> ? init_module_from_file+0x86/0xd0<br /> init_module_from_file+0x86/0xd0<br /> idempotent_init_module+0x17c/0x230<br /> __x64_sys_finit_module+0x56/0xb0<br /> do_syscall_64+0x6e/0x140<br /> entry_SYSCALL_64_after_hwframe+0x71/0x79

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations<br /> <br /> Create subvolume, create snapshot and delete subvolume all use<br /> btrfs_subvolume_reserve_metadata() to reserve metadata for the changes<br /> done to the parent subvolume&amp;#39;s fs tree, which cannot be mediated in the<br /> normal way via start_transaction. When quota groups (squota or qgroups)<br /> are enabled, this reserves qgroup metadata of type PREALLOC. Once the<br /> operation is associated to a transaction, we convert PREALLOC to<br /> PERTRANS, which gets cleared in bulk at the end of the transaction.<br /> <br /> However, the error paths of these three operations were not implementing<br /> this lifecycle correctly. They unconditionally converted the PREALLOC to<br /> PERTRANS in a generic cleanup step regardless of errors or whether the<br /> operation was fully associated to a transaction or not. This resulted in<br /> error paths occasionally converting this rsv to PERTRANS without calling<br /> record_root_in_trans successfully, which meant that unless that root got<br /> recorded in the transaction by some other thread, the end of the<br /> transaction would not free that root&amp;#39;s PERTRANS, leaking it. Ultimately,<br /> this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount<br /> for the leaked reservation.<br /> <br /> The fix is to ensure that every qgroup PREALLOC reservation observes the<br /> following properties:<br /> <br /> 1. any failure before record_root_in_trans is called successfully<br /> results in freeing the PREALLOC reservation.<br /> 2. after record_root_in_trans, we convert to PERTRANS, and now the<br /> transaction owns freeing the reservation.<br /> <br /> This patch enforces those properties on the three operations. Without<br /> it, generic/269 with squotas enabled at mkfs time would fail in ~5-10<br /> runs on my system. With this patch, it ran successfully 1000 times in a<br /> row.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: make sure that WRITTEN is set on all metadata blocks<br /> <br /> We previously would call btrfs_check_leaf() if we had the check<br /> integrity code enabled, which meant that we could only run the extended<br /> leaf checks if we had WRITTEN set on the header flags.<br /> <br /> This leaves a gap in our checking, because we could end up with<br /> corruption on disk where WRITTEN isn&amp;#39;t set on the leaf, and then the<br /> extended leaf checks don&amp;#39;t get run which we rely on to validate all of<br /> the item pointers to make sure we don&amp;#39;t access memory outside of the<br /> extent buffer.<br /> <br /> However, since 732fab95abe2 ("btrfs: check-integrity: remove<br /> CONFIG_BTRFS_FS_CHECK_INTEGRITY option") we no longer call<br /> btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only<br /> ever call it on blocks that are being written out, and thus have WRITTEN<br /> set, or that are being read in, which should have WRITTEN set.<br /> <br /> Add checks to make sure we have WRITTEN set appropriately, and then make<br /> sure __btrfs_check_leaf() always does the item checking. This will<br /> protect us from file systems that have been corrupted and no longer have<br /> WRITTEN set on some of the blocks.<br /> <br /> This was hit on a crafted image tweaking the WRITTEN bit and reported by<br /> KASAN as out-of-bound access in the eb accessors. The example is a dir<br /> item at the end of an eb.<br /> <br /> [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2<br /> [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f]<br /> [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1<br /> [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0<br /> [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206<br /> [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0<br /> [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748<br /> [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9<br /> [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a<br /> [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8<br /> [2.621] FS: 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000<br /> [2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0<br /> [2.621] Call Trace:<br /> [2.621] <br /> [2.621] ? show_regs+0x74/0x80<br /> [2.621] ? die_addr+0x46/0xc0<br /> [2.621] ? exc_general_protection+0x161/0x2a0<br /> [2.621] ? asm_exc_general_protection+0x26/0x30<br /> [2.621] ? btrfs_get_16+0x33a/0x6d0<br /> [2.621] ? btrfs_get_16+0x34b/0x6d0<br /> [2.621] ? btrfs_get_16+0x33a/0x6d0<br /> [2.621] ? __pfx_btrfs_get_16+0x10/0x10<br /> [2.621] ? __pfx_mutex_unlock+0x10/0x10<br /> [2.621] btrfs_match_dir_item_name+0x101/0x1a0<br /> [2.621] btrfs_lookup_dir_item+0x1f3/0x280<br /> [2.621] ? __pfx_btrfs_lookup_dir_item+0x10/0x10<br /> [2.621] btrfs_get_tree+0xd25/0x1910<br /> <br /> [ copy more details from report ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/client: Fully protect modes[] with dev-&gt;mode_config.mutex<br /> <br /> The modes[] array contains pointers to modes on the connectors&amp;#39;<br /> mode lists, which are protected by dev-&gt;mode_config.mutex.<br /> Thus we need to extend modes[] the same protection or by the<br /> time we use it the elements may already be pointing to<br /> freed/reused memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcachefs: Check for journal entries overruning end of sb clean section<br /> <br /> Fix a missing bounds check in superblock validation.<br /> <br /> Note that we don&amp;#39;t yet have repair code for this case - repair code for<br /> individual items is generally low priority, since the whole superblock<br /> is checksummed, validated prior to write, and we have backups.

A vulnerability classified as problematic has been found in PHPGurukul Directory Management System 1.0. Affected is an unknown function of the file /admin/search-directory.php.. The manipulation leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-265212.

In lunary-ai/lunary version 1.2.2, the DELETE endpoint located at `packages/backend/src/api/v1/datasets` is vulnerable to unauthorized dataset deletion due to missing authorization and authentication mechanisms. This vulnerability allows any user, even those without a valid token, to delete a dataset by sending a DELETE request to the endpoint. The issue was fixed in version 1.2.8. The impact of this vulnerability is significant as it permits unauthorized users to delete datasets, potentially leading to data loss or disruption of service.

A vulnerability was found in PHPGurukul Directory Management System 1.0. It has been rated as critical. This issue affects some unknown processing of the file /admin/index.php. The manipulation of the argument username leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-265211.

A vulnerability classified as problematic has been found in SourceCodester Event Registration System 1.0. This affects an unknown part of the file /registrar/. The manipulation of the argument searchbar leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-265203.

A vulnerability was found in SourceCodester Electricity Consumption Monitoring Tool 1.0. It has been declared as critical. This vulnerability affects unknown code of the file /endpoint/delete-bill.php. The manipulation of the argument bill leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-265210 is the identifier assigned to this vulnerability.

In scrapy/scrapy, an issue was identified where the Authorization header is not removed during redirects that only change the scheme (e.g., HTTPS to HTTP) but remain within the same domain. This behavior contravenes the Fetch standard, which mandates the removal of Authorization headers in cross-origin requests when the scheme, host, or port changes. Consequently, when a redirect downgrades from HTTPS to HTTP, the Authorization header may be inadvertently exposed in plaintext, leading to potential sensitive information disclosure to unauthorized actors. The flaw is located in the _build_redirect_request function of the redirect middleware.

A vulnerability was found in SourceCodester Event Registration System 1.0. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the file /registrar/?page=registration. The manipulation of the argument e leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-265201 was assigned to this vulnerability.