In the Linux kernel, the following vulnerability has been resolved:

ipv4: validate checksumstart before completing checksum

If a packet with bad checksum metadata gets into the ipv4 stack, skbchecksumhelp can corrupt the network header and cause a bunch of mischief.

This was discovered and reported by Paulos, and has been reporoduced by others independently since.

We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum.

A more complete validation at input is forthcoming, but needs more work.

In the Linux kernel, the following vulnerability has been resolved:

xfrm: ah6: validate routing header segmentsleft

AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6rearrangerthdr() assumes that segmentsleft is not larger than the number of addresses described by the routing header's hdrlen field.

That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segmentsleft value. With segmentsleft equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access.

Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.

A use-after-free vulnerability was found in the Linux kernel's IPv6 FIB rule lookup path. In fib6rulesuppress(), when a route is suppressed and released via ip6rtputflags(), the res->rt6 pointer is not cleared. If no later rule supplies a replacement route, fib6rulelookup() returns the stale (freed) rt6info to its caller. The subsequent dstrelease() then operates on freed memory, hitting rcurefputslowpath(). A local attacker who can configure IPv6 routing/FIB rules could trigger this to cause a denial of service (kernel crash) or potentially escalate privileges.

In the Linux kernel, the following vulnerability has been resolved:

net: bridge: stop fast-leave after deleting a port group

brmulticastleavegroup() iterates mp->ports with pp = &p->next in its fast-leave path. After brmulticastdelpg() removes p, continuing the loop advances pp through the deleted entry.

If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, brportgroupequal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group.

Fast leave only needs to remove one matching port group. Break after brmulticastdelpg() so the loop stops before dereferencing the removed entry.

In the Linux kernel, the following vulnerability has been resolved:

sctp: prevent peer transport count overflow

sctpassocaddpeer() increments the association's 16-bit transportcount for every new unique peer. Adding the 65,536th transport wraps the count to zero.

SCTP sockdiag uses transportcount to reserve the INETDIAGPEERS payload, then copies one sockaddrstorage for every entry in transportaddrlist. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail.

Reject a new unique peer when transportcount has reached U16MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.

In the Linux kernel, the following vulnerability has been resolved:

sctp: fix authhmacs array size in struct sctpcookie

The authhmacs array in struct sctpcookie is supposed to store a complete SCTPAUTHHMACALGO parameter, which consists of a struct sctpparamhdr followed by N HMAC identifiers.

However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctpparamhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the authhmacs buffer in the cookie.

As a result, sctpassociationinit() copies beyond the end of authhmacs when initializing the association, corrupting the adjacent authchunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctpauthgethmac().

Fix the array size calculation by including the full SCTP parameter header size.

In the Linux kernel, the following vulnerability has been resolved:

pppoe: reload header pointer after devhardheader()

pppoesendmsg() saves a pointer to the PPPoE header before calling devhardheader(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it.

This can happen when a send is blocked in copyfromuser() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head.

Reload the PPPoE header through the skb's network-header offset after device header creation. pskbexpandhead() updates that offset when it relocates the head.

In the Linux kernel, the following vulnerability has been resolved:

sctp: don't free the ASCONF's own transport in DEL-IP processing

sctpprocessasconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctprcv()). For an ASCONF located through its Address Parameter by sctprcvasconflookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address.

sctpprocessasconfparam() rejects a DEL-IP for the packet source address (ADDIP D8, SCTPERRORDELSRCIP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order:

[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

where L differs from the source. The DEL-IP for L passes the D8 check and calls sctpassocrmpeer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctpassocsetprimary() and sctpassocdelnonprimarypeers(): setprimary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primarypath / activepath, and delnonprimarypeers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transportcount of 0 and primarypath/activepath pointing at freed memory.

Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.