dhx

SYN packet #1 is received and added to a request queue for processing.

SYN packet #2 is received and is a retransmit of SYN packet #1. It is matched to SYN packet #1 already in the request queue and now there is shared state between both SYN packets #1 and #2 in the request queue.

CPU #1 takes on the task of processing SYN packet #1.

CPU #2 takes on the task of processing SYN packet #2.

CPU #1 responds back with RST packet #1 (e.g. requested TCP port is not open) and _should_ defer the destruction of the request socket for SYN packet #1, as other CPUs may still be processing the shared state for the request socket as is the case for retransmitted SYN packets.[1] However, this deferred destruction wasn't occurring, and CPU #1 was _immediately_ destroying the request socket/shared state for SYN packet #1.

CPU #2 races with CPU #1 and reads from the request socket/shared state for SYN packet #1 after its _immediate_ destruction by CPU #1.

Linux's IPv6 handling is unaffected because in this IPv6 scenario, there is no shared state between SYN packets #1 and #2 in the request queue. Instead, each request socket has duplicate data.

Someone more knowledgeable can confirm/correct me on the above please.

7.3 (2026-10-18)

7.2.10 (2026-10-11)

6.18.56 (2026-10-11)

6.12.113 (2026-10-15)

6.6.159 (2026-10-15)

6.1.190 (2026-10-15)

5.15.225 (2026-10-15)

The nuance is the Online Safety Act 2021 does not have an "app distribution blocking notice" or "app blacklisting notice" or similar, therefore, I think the effect is Apple can't stop a Russian website distributing apps to Australian users who seek them out, but Apple can use a received "app removal notice" to then blacklist the relevant app on existing devices?

Examples of the type of alternate questions to ask in 2026 may include:

- Does my software/system have a robust architecture where a failure of one component (e.g. RCE in a PHP process) has a minor impact, rather than a catastrophic impact? For example, a minor impact might be just the opportunity for an attacker to chain a PHP RCE with kernel LPE for some common syscall, rather than mass loss of every user's data to the attacker. I raised some PHP web application specific ideas in another thread at [1] but the answer to this question is product-agnostic and should consider microservices architecture vs. monolithic web application with access to everything, and use case/requirements development that considers matters such as users wanting to isolate their own access. For example, allowing bank users read only login for bank accounts vs. separate login for making transfers. Or implementing business process changes such as delayed commit for sensitive user actions--e.g. force delay a bank transfer by 24h and notify the user via various means giving them a chance to undo the transfer before they no longer can.

- How can I keep up-to-date with the latest software/system security architecture trends? What is the equivalent of [2] for learning about architecture patterns to potentially use for a simple eCommerce site, HR/finance web application, etc in 2026? For components of a web application such as interpreter, database server, etc--what options exist for each and how good is the project's choice of software languages, dependencies, etc to offer the strongest security protections in 2026? When was the last time I checked if someone had written an interpreter for PHP, Python, etc in Rust, SPARK, or whatever, or written an interpreter with much more comprehensive unit testing included?

- How quickly can my users or I detect security incidents / deviations of system behaviour from typical state? For example, [3] was discussed on HN today as once such detection mechanism where canary tokens are deliberately littered throughout a system or dataset. The security incident may have already happened, but early detection forces an attacker to burn their vulnerability chain quickly on their most highly prized target and not be able to use it against a mass of targets over a long duration of time.

Vulnerable but perhaps with no impact. If you've setup your web server well, the vulnerable PHP process is sandboxed, at least to some degree, and an attacker executing their own code within the compromised PHP process can't move laterally through your internal networks, write files to disk, read files from disk, etc because you've locked down the PHP process.

In 2026, perhaps it's possible to:

1. Use systemd socket activation with Accept=yes [1] and strict sandboxing applied to a systemd service that executes the PHP interpreter. The result being each incoming request is dealt with inside an isolated PHP process spawned specifically to handle the request. Compromise of a PHP process doesn't impact any other concurrent requests, or any future requests, except through defined sandbox interfaces such as access to a database server socket.

2. For each user of the web application (perhaps including an 'anonymous' user too if anonymous users have access to dynamic content), if using PostgreSQL, create a role in PostgreSQL for each web application user. Then use row-level-security permissions and security barrier views within the database, and have the PHP process accept credentials from the user which are then needed to be passed through to PostgreSQL to login as that individual user.

It's not without some significant downsides:

1. It's complex and you might be the only person in the world trying to use PHP in this secure way. And if you're going this far, for a complex web application, it'd be best to split it into smaller web applications each with their own systemd service defining specific sandboxing constraints. E.g. microservice architecture where "login", "file upload", "user administration" are all separated with different sandboxing constraints applied to each.

2. Performance will suffer and you'll need more resources--for spawning new PHP processes from scratch for each request (although this is already the case with php-fpm which is most widely used), and for dealing with row-level-security in PostgreSQL (see e.g. LEAKPROOF functions).

The more common pattern I've come across on public websites in recent times that might mirror some of the above is client-side JavaScript dynamic rendering with API calls to a GraphQL database exposed on the Internet (using e.g. field-level access control). The user isolation problem is essentially pushed from PHP+PostgreSQL to a GraphQL implementation.

The single biggest problem I came across over a decade ago when maintaining an open source PHP web application was web applications at the time typically having access to a common database server role (often also common between users and administrators) which allowed a web application process to read and sometimes write to the entire database. No use of user-specific roles in database servers and row-level-security/column-level-security authorisation. At the time I don't think PostgreSQL even had row-level-security support built into it. A runaway PHP process could return the entire database to the attacker, or change every single row of data held within the database.

The second biggest and related problem was web applications accepting files uploaded from users, or having to generate reports (maybe with external software) and save them to disk for a user to download, and not being able to ensure a runaway PHP process can't just dump all of those files or reports to an attacker. You might have been able to store the user files (or at least a decryption key for the files) in a database but then you're back to dealing with problem (1) above.

Even a decade ago it was fairly common for web application developers (of the PHP sorts too) to be well aware of the need to make their web root read-only, put the web application source code into a read-only directory outside the web root, execute interpreters such as PHP with "nobody"-like permissions, launch a new interpreter process for each connection (not multiple threads within the same process), firewall off the server the web application sits on so a runaway PHP process can't connect to internal servers, etc. Outside of an attacker messing with a database, most other aspects of PHP web applications at the time were immutable if the web application developer / system administrator had setup the environment correctly.

Is there a solution for (1) and (2) for PHP web application development that has become popular in the proceeding decade?

Both topics are very relevant to the current conflicts of eastern Europe and the middle east. Perhaps I took away the wrong message but I don't think Perun would propose to stockpile interceptor missiles any time soon.

For just one of many examples, see [1] where the Gentoo developer had to submit a patch upstream for a Chromium build toolchain bug that to 99% of experienced Linux users is bordering on unintelligible due to how much specific knowledge is needed to understand the bug.

I've tried to find similar for Finland. The closest I've found is [1] which maps "old forests" which are defined to be over 100 years old (not actually very old). The three examples [2], [3] and [4] are Google street view imagery of nearby "old forests" and all indicate a much higher biodiversity and natural planting than the site Google has cleared. The site Google has cleared and nearby forests are visible in overhead imagery as having a pattern of tree plantings (distinct rows/grid) and show visible disturbance for forestry trails (ground compaction), whereas the "old forest" sites don't have these patterns. The "old forest" sites also show variance in trunk diameters, greater separation between trunks, more forest floor diversity and more tree variety (both taxon and structure). Plantation forests have trees deliberately planted too close to each other to encourage upright growth habit, lower limbs are deliberately removed and trees thinned after some years, all to maximise the number of sawmill-ready trunks. Revegetation planting would look completely different to what occurred at the Google site.

Revegetation planting and ongoing management is also much more expensive to do correctly. It's a struggle to find success stories. Best examples likely involve aerial seeding and complex seed collection and preparation, as well as ongoing manual weed management and introduced species control for 20+ years. There is often a fair bit of complexity to simulating nature to make seeds viable--for example, refer to Przewalski's Horse case study where hoofed animals were reintroduced and found to be essential for embedding seeds at required depth and reshaping the terrain to support seed germination. More examples are water courses upstream having to be cleared of weeds first, introduced animals need to be excluded/culled, etc, etc.

Google street view imagery of the site showing logging completed by June 2026 and logs waiting collection: [1]

Sentinel-2 L2A imagery from 2026-10-11 showing the logged area: [2]

"the Court finds that Plaintiffs are likely to succeed on the merits of their claim that Defendants violated their First Amendment rights through coercion of Facebook and Apple."

My reference to a press freedom index is due to a lack of "countries by freedom of software development" index. If such index existed, the methodology may have some commonality with a press freedom index.

Placing barriers in front of publishing of books, online content, software, etc all leads to some suppression of speech. The question is whether the benefits of the barriers placed outweigh the risks/negatives. In this case, why should anyone care what the passport number or residential address is of a student interested in a career in software development who is writing their first Android game?