Security Feed

In the Linux kernel, the following vulnerability has been resolved: misc: vmw_balloon: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.

In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix memory leak in ubifs_sysfs_init() When insmod ubifs.ko, a kmemleak reported as below: unreferenced object 0xffff88817fb1a780 (size 8): comm "insmod", pid 25265, jiffies 4295239702 (age 100.130s) hex dump (first 8 bytes): 75 62 69 66 73 00 ff ff ubifs... backtrace: [<ffffffff81b3fc4c>] slab_post_alloc_hook+0x9c/0x3c0 [<ffffffff81b44bf3>] __kmalloc_track_caller+0x183/

In the Linux kernel, the following vulnerability has been resolved: wifi: iwl3945: Add missing check for create_singlethread_workqueue Add the check for the return value of the create_singlethread_workqueue in order to avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved: ubifs: Free memory for tmpfile name When opening a ubifs tmpfile on an encrypted directory, function fscrypt_setup_filename allocates memory for the name that is to be stored in the directory entry, but after the name has been copied to the directory entry inode, the memory is not freed. When running kmemleak on it we see that it is registered as a leak. The report below is triggered by a simple program 'tmpfile' just opening

In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync() The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a nu

In the Linux kernel, the following vulnerability has been resolved: Drivers: vmbus: Check for channel allocation before looking up relids relid2channel() assumes vmbus channel array to be allocated when called. However, in cases such as kdump/kexec, not all relids will be reset by the host. When the second kernel boots and if the guest receives a vmbus interrupt during vmbus driver initialization before vmbus_connect() is called, before it finishes, or if it fails, the vmbus interrupt service

In the Linux kernel, the following vulnerability has been resolved: ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume() There is a memory leaks problem reported by kmemleak: unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes): ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<ffffffff81

In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_disksize exceeding i_size problem in paritally written case It is possible for i_disksize can exceed i_size, triggering a warning. generic_perform_write copied = iov_iter_copy_from_user_atomic(len) // copied < len ext4_da_write_end | ext4_update_i_disksize | new_i_size = pos + copied; | WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // update i_disksize | generic_write_end | copied = block_write_end(copi

In the Linux kernel, the following vulnerability has been resolved: block: ublk: make sure that block size is set correctly block size is one very key setting for block layer, and bad block size could panic kernel easily. Make sure that block size is set correctly. Meantime if ublk_validate_params() fails, clear ub->params so that disk is prevented from being added.

In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_mqs: move of_node_put() to the correct location of_node_put() should have been done directly after mqs_priv->regmap = syscon_node_to_regmap(gpr_np); otherwise it creates a reference leak on the success path. To fix this, of_node_put() is moved to the correct location, and change all the gotos to direct returns.

In the Linux kernel, the following vulnerability has been resolved: driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event() The kfree() should be called when memory fails to be allocated for cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be a memory leak, so add kfree() to fix it.

In the Linux kernel, the following vulnerability has been resolved: arm64: acpi: Fix possible memory leak of ffh_ctxt Allocated 'ffh_ctxt' memory leak is possible if the SMCCC version and conduit checks fail and -EOPNOTSUPP is returned without freeing the allocated memory. Fix the same by moving the allocation after the SMCCC version and conduit checks.

In the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe Use devm_of_iomap() instead of of_iomap() to automatically handle the unused ioremap region. If any error occurs, regions allocated by kzalloc() will leak, but using devm_kzalloc() instead will automatically free the memory using devm_kfree(). Also, fix error handling of hws by adding unregister_hws label, which unregisters remaining hws when iomap failed.

The The Events Calendar plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 6.15.2 via the REST endpoint. This makes it possible for unauthenticated attackers to extract information about password-protected vendors or venues.

The issue was addressed with improved checks. This issue is fixed in Xcode 26. Processing an overly large path value may crash a process.

This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Tahoe 26. An app may be able to access protected user data.

A use-after-free issue was addressed with improved memory management. This issue is fixed in Safari 26, iOS 26 and iPadOS 26, macOS Tahoe 26. Processing maliciously crafted web content may lead to an unexpected Safari crash.

A privacy issue was addressed by moving sensitive data. This issue is fixed in macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to access protected user data.