Search: probe, s.a. de c.v

In the Linux kernel, the following vulnerability has been resolved: accel/rocket: clear rdev on device init failure rocket_probe() stores the return value from rocket_device_init() in the file-scoped rdev pointer before checking whether it is an error pointer. If rocket_device_init() fails, rdev is left as an ERR_PTR. The rdev pointer is also used as the marker for whether the shared rocket device has already been initialized. A later core probe can therefore see a non-NULL rdev, skip rocket_device_init(), and dereference the error pointer when reading rdev->num_cores. Save the error code and clear rdev before returning from the rocket_device_init() failure path.

In the Linux kernel, the following vulnerability has been resolved: gpio: mxc: fix race between chained IRQ handler install and probe completion mxc_update_irq_chained_handler() is called before the IRQ domain, the generic IRQ chip, and the port list entry are set up. If an interrupt arrives in that window: - mx3_gpio_irq_handler() calls generic_handle_domain_irq() with port->domain still NULL. - mx2_gpio_irq_handler() walks mxc_gpio_ports, but the port has not been added to the list yet. Additionally, if any of the subsequent probe steps (gpio_generic_chip_init(), devm_gpiochip_add_data(), irq_domain_create_legacy(), or mxc_gpio_init_gc()) fail, the error paths never unregister the chained handler, leaving a dangling handler that points at freed memory. Move the handler installation after all its dependencies are ready and after list_add_tail(), so the handler is never live while the data structures it touches are incomplete, and is never installed if probe fails.

In the Linux kernel, the following vulnerability has been resolved: accel/rocket: search every core slot when a core is removed rocket_remove() decrements rdev->num_cores for each core it removes, while find_core_for_dev() searches slots 0 to num_cores - 1. Unbinding the cores in the order they were bound therefore loses the last one: by the time it is removed the search range has already shrunk past its slot, so find_core_for_dev() returns -1 and rocket_remove() gives up without doing anything. num_cores never reaches zero, rocket_device_fini() never runs, and the file-scoped rdev keeps pointing at a device that is going away. Binding the cores again starts from that stale count, because rocket_probe() takes rdev->num_cores as the slot to fill. On an RK3588, which describes three cores, the second round lands on slots 1, 2 and 3 while rdev->cores was allocated with room for three: rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309 The write to rdev->cores[3] is past the end of the array. Nothing in tree reads the core array often enough to notice, so the overrun is silent today. It turned up while testing a devfreq series on top of this, where a worker walks every core a few times a second, and UBSAN caught the first bool it read out of the overrun entry: UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor Record how many slots were allocated and search all of them. Every core is then found on removal, num_cores reaches zero, the device is torn down and a later bind starts from a clean rdev. This does not make unbinding a single core out of several work. probe still takes num_cores as the slot to fill, so rebinding one core while its siblings stay bound would write over a slot that is already in use, and rocket_open() still reaches for cores[0] whether or not anything is there. Both of those want more thought than a fix should carry. Found by unbinding and rebinding all three cores on an Orange Pi 5 Plus. With this applied, 25 unbind/rebind rounds and 5 module unload/reload rounds run clean there: the cores land in slots 0, 1 and 2 every time, whichever order they are bound in, and the shared supply goes back to a single user after each round.

In the Linux kernel, the following vulnerability has been resolved: scsi: st: Fix use-after-free race between st_remove() and st_open() st_remove() drops the probe reference on the scsi_tape with kref_put() and only afterwards removes its index from st_index_idr. If that was the last reference, scsi_tape_release() frees the structure while it is still published in the idr. scsi_tape_get(), called from st_open(), looks up the tape in st_index_idr and takes a reference under st_ref_mutex and st_index_lock. remove_cdevs() does not wait for opens that are already past chrdev_open(), so an open that is blocked on st_ref_mutex while st_remove() holds it can take the mutex as soon as st_remove() drops it, find the freed tpnt in the idr and call kref_get() on it: BUG: KASAN: slab-use-after-free in st_open Write of size 4 ... st_open (drivers/scsi/st.c:254 drivers/scsi/st.c:1291) chrdev_open ... Freed by task ...: kfree st_remove (drivers/scsi/st.c:4512) Remove the index from the idr before dropping the reference, all under st_ref_mutex. A concurrent scsi_tape_get() now either runs first and holds a valid reference that keeps the tape alive, or runs afterwards and finds nothing, so st_open() fails with -ENXIO. This restores the ordering st_remove() had before the conversion to st_index_idr, where the tape was unpublished from scsi_tapes[] before the final kref_put().

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (21c91b39929f03c30e501726fc2d1c1fa43f17bf2ed77bda52380e563c1171e0) The package advertises itself as a zero-runtime CSS theming kit but on require/import executes a chain of obfuscated JavaScript modules. lib.mjs imports tokens.mjs, which top-level imports cache-warm.mjs — a ~279KB single-line file consisting of a hex-named string array of XOR/base64-encoded blobs decoded at runtime. Three additional sibling modules of the same shape (build-cache.mjs ~203KB, cache-sweep.mjs ~295KB, workspaces.js ~290KB) are shipped and listed in the published files manifest. Alongside the JavaScript loader, the tarball bundles prebuilt N-API native binaries at native/{linux,darwin,win32}/{arm64,x64}/cache-probe.node whose exported symbols implement extensive hypervisor, container, and sandbox detection (VMDetect/VMDetector classes, hypervisor_bit, qemu_fw_cfg, systemd_virt, dockerenv, bluestacks, vbox_module, podman_file, wsl_proc_subdir, amd_sev_msr, azure, chassis_vendor, mac_address_check, is_x86_process_on_arm). None of this has any role in CSS custom-property emission. The README instructs installation as `npm install -D tailwindcss@npm:postcss-semantic-themes`, aliasing the legitimate tailwindcss name onto this package so existing `import 'tailwindcss'` call sites resolve to the obfuscated loader. The combination of an import-time obfuscated loader, multiple additional staged obfuscated payloads, environment-fingerprinting native code to gate execution to non-analyst hosts, and a brandjacking install instruction is the structural shape of a staged supply-chain payload rather than a theming plugin. ## Source: ghsa-malware (d188bb5d3c330ed5c438865b3787cca124861eefe2c8e094e58511bbca437e09) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

A vulnerability in the Linux kernel's ASoC Samsung i2s driver causes an imbalance in runtime power management due to the op_clk clock not being enabled during device probe. This leads to a warning during boot related to clock disablement. The issue is fixed by enabling op_clk in the probe function and disabling it in the remove function.

A vulnerability in the Linux kernel's mmc sdhci-sprd driver involves improper handling of runtime power management (PM) during device removal. The driver enables runtime PM on probe but fails to properly clean up runtime PM on removal, potentially leading to clocks being disabled incorrectly if the device is runtime suspended. This issue was identified through manual code inspection and affects specific Linux kernel versions.

A vulnerability in the Linux kernel's CPSW driver causes the devlink instance to remain registered if port registration fails during the probe process. This occurs because the error handling path does not unregister devlink after a failure in cpsw_register_ports(), potentially leaving stale devlink registrations.

CVE-2026-98904 is a vulnerability in the Linux kernel's mailbox imx driver related to improper power management runtime handling during device probe and removal. The issue involves early usage of the device before probe completion, which can cause improper device shutdown sequences. The fix involves using devm_pm_runtime_enable() to delay enabling runtime power management until after the device is fully registered, ensuring proper ordering of device removal and power management disablement.

@ppa-web-components/ppa-headerfooter is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (1.0.0, 2.0.1, 2.0.0, 1.0.1, 99.0.1, 3.0.0) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (32234bc8ba0c918d154d680b15a1bcb7ae6f6b7d20365c02095842b84e245dce) The package ships a `beacon.cjs` script wired as both the `postinstall` lifecycle hook (`node beacon.cjs`) and a require-time side effect from `index.js`. On install and on `require()`, the beacon POSTs installer identifiers — `os.hostname()`, the install path (`__dirname`), `process.cwd()`, `process.version`, and the package name — to the hardcoded bare-IP plaintext HTTP endpoint `http://185.158.107.175:8787/_ah/dc`. The package otherwise provides no functionality: `index.js` exports a Proxy that returns a no-op function for every property access, so the beacon is the sole purpose of the package. The combination of a scoped name resembling a web-components namespace, a 'Compatibility shim' description, a functionless Proxy stub, and a bare-IP recon beacon is the shape of a dependency-confusion / typosquat probe measuring where the package resolves inside private build environments, typically preceding a targeted follow-up payload. ## Source: ghsa-malware (2d6203081a7ca70c676e9bd017a2350965128b04bb4abed55ac7f82d6d95915c) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

@ppa-web-components/ppa-hotel-collection is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (1.1.0, 1.0.0, 99.0.1, 2.0.1, 3.0.0) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (e442008a433c1edbe8fb25f9b47dd3123f5664672c3901167fc9d3add8a6bd6e) @ppa-web-components/ppa-hotel-collection@1.1.0 is a stub package whose only functional code is a callback beacon. The package.json declares scripts.postinstall: "node beacon.cjs", and the same beacon.cjs is also triggered via the main entry on require(). beacon.cjs collects os.hostname(), __dirname, process.cwd(), and process.version/npm version and POSTs them to the hardcoded bare-IP URL http://185.158.107.175:8787/_ah/dc over cleartext HTTP. The destination is unrelated to any legitimate publisher infrastructure for the @ppa-web-components scope. The package's only export is a no-op Proxy, and the description self-labels as "Compatibility shim." with internal comments noting that a build which "completes and calls back is cleaner evidence" — consistent with a dependency-confusion probe targeting an internal @ppa-web-components namespace. Installing or requiring the package automatically exfiltrates host and path identifiers to attacker-controlled infrastructure, marking the installer's build system as reachable for follow-on targeting. ## Source: ghsa-malware (5c6c67a20abb37db21d16508f031264290a06f2426dc6cb70f74cc3f5d73d3a1) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

@ppa-web-components/ppa-builder is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (0.0.1, 1.0.0, 1.0.1, 99.0.1, 2.0.1, 3.0.0) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (cc4615498b50aa4b5f39a8367c44e6a18d4a7272ae71235716a152b2933d5ddd) The package is described as a 'Compatibility shim' and ships a stub Proxy-based main plus beacon.cjs. The package.json declares scripts.postinstall: 'node beacon.cjs', and the main entry also invokes the same fire() routine on require. On both triggers, beacon.cjs collects installer identifiers — os.hostname(), __dirname (install path), process.cwd(), process.version, and the package name — and POSTs them in cleartext to the hardcoded bare-IP endpoint http://185.158.107.175:8787/_ah/dc. The destination is not a registry, publisher, or any documented infrastructure; it is a plain-HTTP bare IP with no TLS. An inline source comment states that a build that completes and calls back is cleaner evidence, confirming the artifact's purpose is to signal successful resolution and execution on installer machines. Combined with a scoped name resembling an internal namespace and no real library functionality, this matches the dependency-confusion / namesquat callback-probe shape. ## Source: ghsa-malware (25f793f86454c72ad9c76b0ef0948c16f82bc42fb58d8d9f8e68224e52eb92fd) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

@ppa-web-components/ppa-searchform is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (1.0.0, 1.0.1, 2.0.1, 0.0.1, 3.0.0, 1.1.0, 99.0.1, 2.0.0) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (c9b929e77e53b5f528d874024d0cf8cfe4a0e34845796964600b0e1511e6a49c) The package ships a `beacon.cjs` that is wired to run both via the `postinstall` lifecycle script and from top-level `index.js` on `require()`. On execution it collects host identifiers (hostname, install path, current working directory, Node.js version) and POSTs them to a hardcoded bare-IPv4 endpoint over plaintext HTTP at http://185.158.107.175:8787/_ah/dc. The destination is not a publisher-owned domain. The package's `index.js` exports a `Proxy` that returns no-op functions for every property access, so the module provides no real functionality — its only effect on install or import is the beacon callback. The combination of a non-functional shim under an organisation-shaped scope with a reconnaissance beacon fired at install and import time is the fingerprint of a dependency-confusion / namesquat probe that reports successful resolution and build inside a victim's environment. ## Source: ghsa-malware (20e1280405965a158dc583a69a89a290211d37dc991ca293e84cf94cf86e2e6a) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

@ppa-web-components/ppa-navigation is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (1.0.1, 1.0.0, 2.0.0, 99.0.1, 3.0.0, 2.0.1) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (c88c344e72bb7cf5ae6f5e6185a1024caf8b96bce96584d448609ab78cd894af) The package is a shim whose only functional payload is a beacon. package.json declares a postinstall that runs `node beacon.cjs`, and `index.js` additionally invokes `require('./beacon.cjs').fire()` on load, so the beacon fires both at `npm install` and whenever any consumer `require`s the package. The beacon POSTs the installer's hostname, install path, current working directory, and Node version to the hardcoded bare-IP plain-HTTP endpoint `http://185.158.107.175:8787/_ah/dc`. The destination is not a registry, not a documented first-party service, and the plain-IP + non-standard port shape is inconsistent with any legitimate vendor telemetry. The package otherwise exports a Proxy that returns no-op functions for every property and self-describes as a 'Compatibility shim', so the beacon is the entire payload. The scoped name `@ppa-web-components/ppa-navigation` has the shape of a dependency-confusion or typosquat probe against an internal `@ppa-web-components` namespace. ## Source: ghsa-malware (b810a6b75e53293eb696e1672c7bbb4c9681eb89895bfc8d080aa527575070e5) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Rclone versions from 1.64.0 up to but not including 1.75.2 contain an authentication bypass vulnerability in the serve webdav feature. This flaw allows unauthenticated attackers to bypass authentication by sending OPTIONS requests. Exploitation enables attackers to probe arbitrary paths and use the Allow header values to determine the existence of files or collections, effectively allowing namespace enumeration.

@sxm-web/client-sdk-core is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (0.0.1, 1.0.0, 1.0.1, 2.0.0, 1.1.0, 3.0.0, 13.3.7) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (8d53280e50e3f0ad06e3ab6e3685856cd774465fd6d4461d64e22caad4ee94fc) @sxm-web/client-sdk-core@1.0.1 is a stub package whose only functional code is a beacon. The declared postinstall script runs `node beacon.cjs`, and the same beacon is also invoked at require time from index.js. The beacon collects installer-side identifiers (hostname, install path, current working directory, Node.js version, package name) and POSTs them in cleartext over plain HTTP to the hardcoded bare-IP endpoint http://185.158.107.175:8787/_ah/dc, which is unrelated to any legitimate registry or publisher infrastructure. The package's `main` returns a Proxy that produces no-op functions for every accessed property, so the package provides no advertised functionality — the install itself is the payload. The scoped name `@sxm-web/client-sdk-core` combined with a `Compatibility shim` description is consistent with a dependency-confusion probe aimed at an internal/private SDK namespace, where the beacon's purpose is to confirm successful resolution against private names and to disclose the resolving host's identity and filesystem layout to the operator at the bare IP. ## Source: ghsa-malware (8a5670fe68642a259935664dbac1c7c569c1af0b09253570a72909b92c7ac1c5) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

@greenlake/common-context is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (99.0.1, 3.0.0) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (8ee1e5c23e641cce920808500ad850f4965adeb982b4c14233901c80c2cfb039) The package self-describes as a 'Compatibility shim' and exports an inert Proxy that returns no-op functions for every property, providing no functional API. Its only runtime behavior is a beacon in beacon.cjs that fires both from the npm postinstall lifecycle hook and on require() via index.js. The beacon collects the installer's OS hostname, __dirname install path, and process.cwd() (which commonly embed the Unix username and internal project/repo names) along with Node version, and POSTs them as JSON to the hardcoded plaintext bare-IP endpoint http://185.158.107.175:8787/_ah/dc with an x-beacon-package header identifying the resolving package. The scoped name @greenlake/* mimicking an internal namespace, the inert public API, and the automatic callback to a hardcoded bare-IP operator on install and import together match the shape of a dependency-confusion probe: resolving this package on an installer's machine silently discloses internal host, user, path, and namespace information to an external operator the installer did not opt into. ## Source: ghsa-malware (09b757ef91607a1bfe1b7e02eb0fc5e2d2647503898e30d04769ac1a5fc5385b) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

@greenlake/auth is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (3.0.0) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d51386d7bf7b3357a9ea920b99fa08f3c2d37532e877f33a5d8d0a78c12702b5) The package declares `postinstall: node beacon.cjs` and additionally fires the same beacon from `index.js` on require(). The beacon POSTs a JSON payload containing `os.hostname()`, `__dirname` (install path), `process.cwd()`, and the Node version to the hardcoded plain-HTTP bare-IP endpoint `http://185.158.107.175:8787/_ah/dc`, which is unrelated to any `@greenlake` publisher infrastructure. The package otherwise ships no functional code: `index.js` self-describes as a 'Compatibility shim' and exports a Proxy whose `get` trap returns a no-op for every property access. The shape — a `@scope/<name>` no-op shim whose only behavior is identifying the installing host to an attacker-controlled IP on `npm install` — matches the dependency-confusion probe pattern, where a public package is published under an internal scope name to map which corporate installers resolve to the public registry. ## Source: ghsa-malware (e39ad6eeb6fd18f5aeff7b616ce8bfeb8f75d50f2ac28bca24a594dfa83b1510) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

In the Linux kernel, the following vulnerability has been resolved: ipv4: stop PMTU walk when nexthop group shrinks Commit 7d3f3b4367f3 ("net: ipv4: Cache pmtu for all packet paths if multipath enabled") made __ip_rt_update_pmtu() update every path. For nexthop objects, fib_info_num_path() and fib_info_nhc() independently load nh->nh_grp. RCU protects each group's lifetime but does not make the loads observe the same group. If replacement shrinks the group after the loop accepts an index, fib_info_nhc() returns NULL and update_or_create_fnhe() dereferences it. A deterministic probe only widened the existing window between the real operations. On v7.2, an RTM_NEWNEXTHOP replacement published a one-member group after the PMTU reader accepted index 1 from a two-member group, producing: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: update_or_create_fnhe+0x45/0x15b0 Stop when the indexed path is absent. Groups are dense, so no later index exists in that snapshot. The same real-writer window completed 114,423 PMTU iterations without an oops with this check. A reproducer is available on request. Replacement requires CAP_NET_ADMIN in the network namespace. Where unprivileged user namespaces are permitted, a local user can obtain it in a new user and network namespace.