In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers The irq handlers take a struct device pointer and call dev_get_drvdata() to obtain the driver data. However, the driver data is only set at the end of probe, after devm_request_irq(), so an interrupt taken in between causes the handlers to pass a NULL pointer to readl() and crash. Pass the private data directly as the devm_request_irq() argument instead of the device pointer, matching what the handlers expect.
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: dispcc-eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK Eliza EVK (eliza-cqs-evk.dts) does not have display enabled, however its Display Clock Controller is enabled and references parent clocks from DSI PHYs, which causes clock reparenting issues during probe (init) and warning on Eliza EVK: disp_cc_mdss_mdp_clk_src: rcg didn't update its configuration. WARNING: drivers/clk/qcom/clk-rcg2.c:136 at update_config+0xd4/0xe4, CPU#1: udevd/273 ... update_config (drivers/clk/qcom/clk-rcg2.c:136 (discriminator 2)) (P) clk_rcg2_shared_disable (drivers/clk/qcom/clk-rcg2.c:1471) clk_rcg2_shared_init (drivers/clk/qcom/clk-rcg2.c:1540) __clk_register (drivers/clk/clk.c:3959 drivers/clk/clk.c:4368) devm_clk_hw_register (drivers/clk/clk.c:4448 (discriminator 1) drivers/clk/clk.c:4672 (discriminator 1)) devm_clk_register_regmap (drivers/clk/qcom/clk-regmap.c:104) qcom_cc_really_probe (drivers/clk/qcom/common.c:418) qcom_cc_probe (drivers/clk/qcom/common.c:445) disp_cc_eliza_probe (dispcc-eliza.c:?) dispcc_eliza platform_probe (drivers/base/platform.c:1432)
In the Linux kernel, the following vulnerability has been resolved: Input: psxpad-spi - set driver data before use psxpad_spi_suspend() retrieves the controller state with spi_get_drvdata(), but probe never stores it, so suspend dereferences a NULL pointer. Store it during probe.
WWBN AVideo contains a path traversal vulnerability in the API get_api_login_code endpoint that allows unauthenticated attackers to delete arbitrary .log files by supplying directory traversal sequences in the code parameter. Attackers can exploit this to destroy audit logs and probe for file existence on the server, with the vulnerability enabling both file deletion and information disclosure about the filesystem.
Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 5.0.0, Wallos lets any authenticated user store an arbitrary SMTP host — including private and cloud-metadata IP addresses — in their personal email notification settings, with no server-side SSRF validation. When the scheduled notification cron job runs, it passes the stored host directly to PHPMailer, causing the Wallos server to open an outbound TCP connection to whatever address the attacker specified. This gives a low-privileged attacker a reliable mechanism to probe internal network services from the server's perspective. This issue has been patched in version 5.0.0.
Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 4.9.6, POST /endpoints/notifications/testemailnotifications.php accepts smtpaddress and smtpport from POST body with zero SSRF validation. PHPMailer connects to attacker-supplied host:port. Every other notification endpoint uses ssrf_helper.php but email was missed. Any authenticated user can probe internal network, cloud metadata. This issue has been patched in version 4.9.6.
The npm package 'autobahn-electron-probe' version 99.99.1 has been identified as malicious by the OpenSSF Package Analysis project. It is considered malicious because it executes one or more commands associated with malicious behavior. There is no CVSS score or detailed technical exploit information available. No patch or remediation guidance is provided. No known exploits in the wild have been reported.
In the Linux kernel, the following vulnerability has been resolved: i2c: amd-mp2: Unregister callback on adapter add failure amd_mp2_register_cb() stores the platform I2C context in the MP2 PCI driver's callback table before the adapter is registered. If i2c_add_adapter() fails, probe returns and devres frees the context, but the PCI driver can still dereference the stale pointer from its IRQ and system-sleep callbacks. Unregister the callback before returning the adapter registration error.
In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Shutdown and free rx mailbox channel A mbox rx channel is requested using mbox_request_channel_byname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rx_chan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rx_chan correctly.
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: gc2235: fix UAF and memory leak gc2235_probe() handles its error paths incorrectly. If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free. If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked. gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe(). Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.
In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - only expose sysfs attributes on control interface When the driver was converted to use the driver core to instantiate device attributes (via .dev_groups in the usb_driver structure), the attributes started appearing on all interfaces bound to the driver. Since the ims-pcu driver manually claims the secondary data interface during probe, the driver core automatically creates the sysfs attributes for that interface as well. However, the driver only supports these attributes on the primary control interface. Data interfaces lack the necessary descriptors and internal state to handle these requests, and accessing them can lead to unexpected behavior or crashes. Fix this by updating the is_visible() callbacks for both the main and OFN attribute groups to verify that the interface being accessed is indeed the control interface.
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer
rmi_f54_work() reads a diagnostics report from the device into
f54->report_data, sizing the transfer with rmi_f54_get_report_size():
report_size = rmi_f54_get_report_size(f54);
...
for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) {
int size = min(F54_REPORT_DATA_SIZE, report_size - i);
...
rmi_read_block(.., f54->report_data + i, size);
}
report_data is allocated once at probe from F54's own electrode counts
(array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))),
but rmi_f54_get_report_size() computes the size from
drv_data->num_*_electrodes when those are set, i.e. from the F55
function's electrode counts. Both counts come straight from device
queries (F54 and F55 each report up to 255 electrodes) and nothing
constrains the F55 counts to the F54 ones.
A malicious or malfunctioning RMI4 device that reports larger F55
electrode counts than its F54 counts makes report_size exceed the
allocation, so the read loop writes past report_data (and the V4L2
dequeue memcpy() then reads past it). On conforming hardware the F55
configured electrodes are a subset of the F54 physical electrodes, so
report_size never exceeds the buffer and well-behaved devices are
unaffected.
Record the allocation size and reject a report that does not fit,
mirroring the existing zero-size check.
In the Linux kernel, the following vulnerability has been resolved: block: stop the timeout timer when releasing a never added disk disk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket. Commit 6f8191fdf41d ("block: simplify disk shutdown") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it. nvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed: BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340 Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621 blk_sync_queue+0x22/0x40 block/blk-core.c:222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264 Allocated by task 34: __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146 Freed by task 0: blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857 The queue being synced there is ctrl->admin_q, only a victim sharing a timer wheel bucket with the freed queue's dangling entry; other runs tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work(). Failing nvme_alloc_ns() with a debug patch makes it deterministic: one leaked timer trips KASAN within seconds, while 1987 patched releases produced no splat. Stop the timer and the queue work items before blk_mq_exit_queue(), like blk_mq_destroy_queue() does. Found by FuzzNvme.
A NULL pointer dereference vulnerability was identified and fixed in the Linux kernel's firewire ohci driver. The flaw occurs during error handling in the driver's probe function when the asynchronous receive context is not properly initialized but is still released, leading to a crash. This issue has been resolved by adjusting the cleanup logic to avoid dereferencing uninitialized pointers.
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (deb78208f7aa932298e92a8c241ed970296c567a273fc21013dd83bb7916e81b)
On `npm install`, package.json's preinstall hook runs index.js which harvests installer host identifiers — os.hostname(), os.userInfo() username, local IPv4 addresses, home directory, INIT_CWD, public IP (fetched from api.ipify.org / icanhazip.com / ifconfig.me), DNS resolver IP/subnet, and the parent project's package.json metadata (name, author, repository, homepage) — and transmits them to the hardcoded Interactsh-style callback host `da51rv0hb2uc72tg4gvgdepinjcallbk1.oast.fun`. Exfiltration uses two channels: an HTTPS/HTTP POST to `/poc/<uuid>` on the callback host, and a hex-encoded DNS covert channel that splits the JSON payload into ≤60-character subdomain labels resolved against the callback host, designed to bypass egress filters that block outbound HTTP but permit DNS. The version number (999.9.12) and package name are consistent with a dependency-confusion probe.
## Source: ossf-package-analysis (d7cde5bd15beab8488f3b3b6bde2f17fff6c148ef2d575613762f337bd1c8281)
The OpenSSF Package Analysis project identified 'fund-list-filter' @ 999.9.12 (npm) as malicious.
It is considered malicious because:
- The package communicates with a domain associated with malicious activity.
In the Linux kernel, the following vulnerability has been resolved: watchdog: at91sam9_wdt: prevent timer rearm during teardown at91_ping() rearms the watchdog timer from its callback. timer_delete() neither waits for a running callback nor prevents it from rearming the timer, so probe failure or driver removal can leave the timer accessing the devm-allocated at91wdt after it has been freed. Use timer_shutdown_sync() on both teardown paths. It waits for a running callback and rejects any attempt by the callback to rearm the timer.