Jorropo

**Name of the Vulnerable Software and Affected Versions** Boxo versions 0.4.0 through 0.5.0 **Description** An attacker can cause a Bitswap server to allocate and leak unbounded amounts of memory by sending many `WANT BLOCK` and or `WANT HAVE` requests which are queued in an unbounded queue, with allocations that persist even if the connection is closed. This affects users accepting untrusted connections with the Bitswap server and also affects users using the old API stubs at `github.com/ipfs/go-libipfs/bitswap` because users then transitively import `github.com/ipfs/go-libipfs/bitswap/server`. **Recommendations** Update Boxo to version 0.6.0 or later Update Boxo to version 0.4.1 As a temporary workaround, consider refactoring your code to use the new split API that will allow you to run in a client-only mode using: `github.com/ipfs/boxo/bitswap/client`. The server now limits how many wantlist entries per peer it knows, and this can be configured using the `MaxQueuedWantlistEntriesPerPeer` option. The server now properly clears state about peers when they disconnect. The server now ignores CIDs above some size, and this can be configured using the `MaxCidSize` option. The server now closes the connection if an inline CID is requested.

**Name of the Vulnerable Software and Affected Versions** go-unixfs versions prior to 0.4.3 **Description** The issue is caused by trying to read malformed HAMT sharded directories, which can lead to panics and virtual memory leaks. If untrusted user input is being read, an attacker can trigger a panic due to a bogus `fanout` parameter in the HAMT directory nodes. **Recommendations** For versions prior to 0.4.3, upgrade to version 0.4.3 to resolve the issue. For users unable to upgrade, do not feed untrusted user data to the decoding functions as a temporary workaround.

**Name of the Vulnerable Software and Affected Versions** go-bitfield (affected versions not specified) **Description** The issue arises when untrusted user input is fed into the size parameter of `NewBitfield` and `FromBytes` functions, allowing an attacker to trigger `panic`s. This occurs when the `size` is not a multiple of `8` or is negative. Although there was a note in the `NewBitfield` documentation, it was incomplete and missing from `FromBytes`'s documentation. The problem has been addressed by returning an error if the size is incorrect. **Recommendations** To resolve the issue, users are advised to upgrade to a version where the `NewBitfield` and `FromBytes` functions return an error if the size is not a multiple of 8 or is negative. For users unable to upgrade, ensure that `size` is a multiple of 8 and not negative before calling `NewBitfield` or `FromBytes`. As a temporary workaround, consider checking the condition `size%8 == 0 && size >= 0` yourself before calling `NewBitfield` or `FromBytes`.

**Name of the Vulnerable Software and Affected Versions** go-unixfsnode versions prior to 1.5.2 **Description** The issue is caused by a bogus fanout parameter in the HAMT directory nodes, which can lead to panics and virtual memory leaks when trying to read malformed HAMT sharded directories. If untrusted user input is being read, an attacker can trigger a panic. This is a concern for users who are reading untrusted input. **Recommendations** For versions prior to 1.5.2, users are advised to upgrade to version 1.5.2 or later to resolve the issue. As a temporary workaround, consider limiting the fanout to <= 1024 to avoid attempts of arbitrary sized allocations. There are no known workarounds other than upgrading.