AWS says a billing software bug caused some customers to see wildly inflated estimated charges, including reports of accounts showing bills in the billions or even trillions of dollars. The Register reports: An open issue on the AWS Health Dashboard (archived copy at the time of writing) popped up at 1:33 am Pacific time on Friday informing users that Cost Explorer was "reflecting inaccurate estimated billing data." As of writing, the issue is still unresolved despite AWS trying several different things to get it fixed. The company apparently identified the root cause within an hour and a half of beginning its investigation, only describing it as "an issue with unit pricing within the estimated billing computation subsystem."

AWS followed up by pausing estimated bill updates, saying customers would continue to see the inflated figures already displayed, but that those estimates would not increase further. "The displayed billing estimates do not reflect actual usage and charges," AWS explained, noting that customers don't need to take any action, like, we imagine, flooding the help portal with tickets telling them what they already know, for instance.

"Once the issue has been mitigated, we expect full resolution to take multiple hours as we work through recomputing the estimated billing data," AWS added. After we first published this article, Amazon updated the issue page to indicate that it had identified the root cause and mitigated the underlying issue. The company says that it's begun backfilling data in the Cost Management Console to correct billing numbers, and that all customers should see corrected amounts by Saturday, July 18 at noon pacific time.

Linus Torvalds says the Linux kernel will not ban AI-assisted coding tools, and if anti-AI absolutists have a problem with that, they can "fork it" or "walk away." An anonymous reader quotes a report from Ars Technica: Writing in a lengthy post on the Linux kernel mailing list this week, Torvalds said that "Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away." The statement came amid a lengthy thread arguing about the use of Sashiko, an "agentic Linux kernel code review system" that its creators claim can, in tests, independently find 53.6 percent of the bugs that would end up being fixed by human coders in later commits. But the tool can also waste maintainers' time by sending "false positive" reports of bugs that don't exist, at a rate Sashiko's maintainers estimate is "well within [the] 20% range."

In discussing whether maintainers should be subjected to a flood of these kinds of automated, AI-powered bug report emails (true or false), one poster cited the Software Freedom Conservancy's recent statement that the open source community "should support, not just tolerate, those who outright reject LLM-gen-AI systems" and that "every FOSS contributor deserves self-determination regarding LLM-gen-AI." In the face of that statement, Torvalds said that he rejects those who demand that their open source projects not accept any LLM-generated code or revisions. "We're not forcing anybody to use [LLM tools], but I will very loudly ignore people who try to argue against other people from using it," Torvalds said.

Torvalds said his position on this is a pragmatic one that's "based on technical merit. Not fear of new tools." And when it comes to utility, Torvalds said that "AI is a tool, just like other tools we use. And it's clearly a useful one. It may not have been that 'clearly' even just a year ago, but it's no longer in question today. Anybody who doubts that clearly hasn't actually used it." [...] While Torvalds acknowledged that "AI isn't perfect," he urged detractors to compare the output of these tools to the performance of human code maintainers. "Anybody who points to the problems at AI had better be looking in the mirror and pointing at themselves at the same time," Torvalds wrote. "Because it's not like natural intelligence is always all that great either."

An anonymous reader quotes a report from Krebs on Security: Microsoft today released software updates to plug at least 570 security holes in its Windows operating systems and other software, almost triple the number of vulnerabilities the software giant fixed in its record-smashing Patch Tuesday release last month. Microsoft attributed the burgeoning patch counts to vulnerability discoveries aided by artificial intelligence. Nearly 60 of the bugs quashed in July's Patch Tuesday earned a "critical" severity rating, meaning miscreants or malware could use them to seize remote control over a Windows device with little or no help from the user. Microsoft also addressed three zero-day flaws, including two that are already being exploited in the wild.

Two of the zero-day weaknesses allow an attacker to elevate their user rights on a Windows system, as do approximately 250 other elevation of privilege flaws fixed this month; they include CVE-2026-56155 - an Active Directory Federation Services bug -- and CVE-2026-56164, a Microsoft Sharepoint vulnerability. CVE-2026-50661 is a security feature bypass in Windows BitLocker that could allow attackers to gain access to encrypted data if they have physical access to the device. Microsoft said this bug has been detailed publicly, but that it is not aware of any active exploitation.

In a blog post on July 9, Microsoft Executive Vice President Pavan Davuluri wrote that Windows users will notice "a higher volume of security updates included in each security release" as a result of AI aiding in the discovery of vulnerabilities. "The pace of vulnerability discovery is changing with advances in AI making it possible to find more issues, faster, across more code, with new mechanisms that can accelerate both discovery and analysis," Davuluri wrote.

Linus Torvalds once said LLMs might bring a 10X increase to programmer productivity. But speaking at Open Source Summit India 2026, he now says that number was "not scientific," reports ZDNet. "That was pulled out of my ass number, obviously." Today, he continued, "we're at the point where hopefully it creates more productivity than it takes away," but "we certainly saw more junk being generated by LLMs than we saw useful code up until the like early this year.... it can actually be a huge drain on resources when it takes humans a lot of effort to figure out that, hey, this machine-generated report was not true." Even now, he said, "most of the good ones require more than just the LLM," because "we've had to push back quite a bit... if you find a bug with an LLM, it's not enough to just ask the LLM to make a bug report and then throw it over the fence to us. We want to see a suggested patch; we want to see the human who ran the LLM act as a kind of back-and-forth."

Torvalds described many AI-generated patches as "mindless band-aid kind of patches... they may fix the immediate problem, but the kind of bug remains, and it just is waiting in the hallway to hit you in another place." For his own toy projects, he uses LLMs as prototypers: "I use them as a way to prototype things... quite often the code is not usable in that form, but it's a great way to try something out," while insisting that for kernel-level fixes, "LLMs, in my experience, have not been at that level yet."

Torvalds acknowledged that some AI-found issues have been "absolutely, stunningly, I mean, interesting in a painful kind of way," especially security problems that "show up in the technology press two days later." Despite the embarrassment, he said, "I'm very much not a shoot-the-messenger kind of person. I think we're much better off with LLMs finding bugs, even when they are embarrassing, and they are things that we should probably have found two decades ago."
Torvalds also said he's using AI "for my own toy projects... Every time I travel to some new place, and this is the first time I've been to India, I send the kids pictures of where I am, and for some strange reason, Godzilla seems to follow me around and gets added to those pictures."

ZDNet notes that Torvalds concluded, "There are many useful and less useful uses for AI," and "I think Godzilla is a great place to stop."

Thanks to Slashdot reader joshuark for sharing the article.

Chinese AI systems "have matched the performance of Anthropic's powerful model Mythos in some cybersecurity scenarios," reports the Wall Street Journal.

They call it "a development poised to reset the global tech race and pressure the White House in its overhaul of U.S. AI policy." Security researchers said that a new AI model, released this month by China's Zhipu AI, also known as Z.ai, can match the latest U.S. models when it comes to finding security bugs, although it still lags behind Anthropic's and OpenAI's products in other tasks. Overall, the capability gap between top U.S. models and those built by Chinese companies has narrowed significantly, and use of Chinese AI systems has surged as businesses seek to rein in runaway costs. A host of companies, including Microsoft, are weighing how they can offer Chinese models on their platforms, a development that is set to alter the balance of power among tech companies...

Unlike models from Anthropic or OpenAI, Zhipu's GLM-5.2 is open-weight. That means it can be downloaded and run on hardware operated by anybody and can be modified and used without supervision. Open-weight models are ideal for users who want unfettered access to systems they control, but they are also ideal for hackers, who can run them in the shadows. GLM-5.2 has ranked as one of the 10 most-used AI models, according to data from OpenRouter, a company that provides access to more than 400 AI models. In some benchmarking tests, according to the cybersecurity company Semgrep, GLM-5.2 bested Anthropic's Claude Opus 4.8 model, which was released in May. When given further instructions, Opus 4.8 and GLM-5.2 can match Mythos in bug-finding ability, according to researchers...

"Banning Fable while selling chips China needs to develop its own version is a gift to China," said Saif Khan, a distinguished technology fellow at the Institute for Progress think tank who worked on export restrictions in the Biden administration. The U.S. needs to maximize the use of Mythos and comparable models to harden its cyber defenses while it can, he added. Among the Mythos 5 and Fable 5 users that had lost access before Friday's decision to restore Mythos 5 access for some trusted entities: the National Security Agency, which had been testing the tools and found them impressive in trials, according to people familiar with the matter... "It is incentivizing companies across the globe to use cheaper but very capable Chinese open-weight models, while at the same time undermining the U.S. AI industry," said Niels Provos, a researcher who led security teams at Google and Stripe. "I don't understand it."
Thanks to long-time Slashdot reader schwit1 for sharing the article.

A 29-year-old bug in the Squid web proxy, dubbed Squidbleed and tracked as CVE-2026-47729, can let an authorized proxy user retrieve fragments of another user's cleartext HTTP requests, including credentials and session tokens. The security researcher who reported the flaw credited Anthropic's Claude Mythos Preview for the discovery. The Hacker News reports: Squid describes this as an attack by a trusted client: someone already permitted to use the proxy, not any random host on the internet. That matches Squid's usual home, shared networks like schools, offices, and public Wi-Fi. In those setups, the attacker is just another user of the same proxy. The leak also only reaches traffic that Squid can read. Normal HTTPS rides an opaque CONNECT tunnel, so Squid never sees inside it; the exposed traffic is cleartext HTTP, plus TLS-terminating setups where Squid decrypts and inspects. The attacker also needs the proxy to reach an FTP server they control on port 21. Both FTP and that port are on by default.

[...] If you patch, verify the fix, not just the version. Confirm the guard is in FtpGateway.cc, or check your distribution's backport, since distros ship their own builds (Debian packages Squid 5.7). The public thread is still inconsistent: maintainer Amos Jeffries first said Squid 7.6 carried the fix, then corrected that to 7.7, and on June 22 Debian's Salvatore Bonaccorso noted the referenced commit looks like it is already in 7.6. The fix is small, a null-terminator check before the vulnerable strchr calls, merged to the development branch in April and v7 in May. Squid 7.6 does separately patch CVE-2026-50012, an unrelated cache_digest heap overflow.

The cleaner move is the one the researchers recommend anyway: turn FTP off. Chromium dropped FTP years ago, and most networks carry almost none of it, so disabling it removes this attack surface for free, whatever build you run. The risk is real but bounded. SUSE rates it moderate, CVSS 6.5, and the vector explains the score: the attacker needs proxy access (low privileges), and the only impact is confidentiality, nothing on integrity or availability.

Microsoft has accidentally introduced a bug in Outlook for Mac that omits the original message from email replies, making it difficult for recipients to follow conversation history. Until Microsoft releases a fix, its suggested workaround is to roll back from version 16.110 and disable automatic updates, which is "great for users in full control of their devices -- not so good for anyone with a managed device," notes The Register. "Administrators with fleets of Macs running Outlook should brace for helpdesk tickets." From the report: In some instances, having a user copy and paste the salient bits of the email they are responding to might not be such a bad thing. We've all had emails that required epic amounts of scrolling to find what started the conversation, so forcing users to think about what they actually need to include is no bad thing. However, disrupting user workflows without warning -- well, that is undoubtedly a bad thing.

This is, after all, one of the most basic things an email client needs to do, so shipping a product with a bug that breaks this functionality says more about Microsoft's approach to quality than anything else.

Tech Times reports: Linux 7.2's merge window closed out a cleanup campaign on Friday that most kernel developers had stopped expecting to see end: the complete removal of strncpy(), a C string-copy function that the kernel's own documentation labels "actively dangerous," from every subsystem, driver, and architecture-specific file in the kernel source tree.

The merge landed June 20, 2026. After around 362 commits spread across six years of incremental work, no call site using the function remained, and the function itself — including the last per-CPU-architecture optimized implementations — was struck from the source. The removal matters beyond housekeeping. strncpy() is a persistent source of a specific class of memory error: kernel buffers that contain sensitive data can leak bytes past an unterminated string boundary, a pattern that enables memory disclosure vulnerabilities. Eliminating the function from the tree removes that entire class from the kernel's attack surface — and, critically, makes strncpy() unavailable to any future contributor, turning a best-practice suggestion into an enforced policy.
Phoronix notes it's replaced by five different functions: In place of strncpy, Linux kernel code should use strscpy() for NUL terminated destinations, strscpy_pad() for NUl-terminated destinations with zero-padding, strtomem_pad() for non-NUL-terminated fixed-width fields, memcpy_and_pad() for bounded copies with explicit padding, or memcpy() for known-length memory copies.
"The reason five functions were needed," explains Tech Times, "is that different parts of the kernel were using strncpy() for five semantically distinct memory operations — each with a different intent, different termination requirement, and different padding behavior. " The original function obscured all of those differences under a single ambiguous name. The 362-commit campaign to replace it was, in effect, a codebase-wide audit that forced every call site to declare its actual intent in code That is an engineering outcome with lasting value: the kernel's string-handling semantics are now explicit where they were previously implicit, and future maintainers can read a function name and understand what a copy operation actually does.

Researchers have disclosed a new unpatchable BootROM exploit affecting Apple devices with A12, A13, S4, and S5 chips. The attack requires physical USB access and DFU mode, but can let an attacker run code before iOS loads, bypass signature checks, and boot modified software. 9to5Mac reports the details: In a highly detailed technical post published today, the Paradigm Shift Team details usbliter8, a new exploit that "leverages both a hardware bug in the USB controller and a specific configuration flaw present in the device firmware" and cannot be patched. The PS Team explains that ahead of today's disclosure, it shared its findings and worked with Apple Product Security to coordinate the release. The researchers also thanked Apple's security team for its "prompt response, constructive engagement, and cooperation throughout" the process.

In a nutshell, this bug affects the following Apple SoCs: A12, S4, S5, and A13. [...] They add that "technical support for A12X/Z is possible," but "it is not currently implemented." That could add the 2018 and 2020 iPad Pro lineups to the list. The way usbliter8 works is: it sends specially crafted data to a device over USB while it is in DFU mode, confusing the USB controller and causing it to write data to the wrong part of memory. That gives an attacker with physical access to the device control over its startup process. From there, they can run their own code before iOS loads, bypass signature checks, and boot modified system software.

Importantly, the exploit does not affect or compromise the device's Secure Enclave, which in practice means that data such as passcodes and encrypted user data remain secure. That said, PS Team says that "although usbliter8 doesn't affect SEP itself, it opens up wider attack vectors to compromise the Secure Enclave," adding that "by releasing this exploit publicly, we hope to highlight the real-world impact of these hardware flaws and contribute to a broader understanding of modern SecureROM security." [...] Given that this is also an unpatchable exploit, the researchers note that "affected users should be aware that migrating to newer hardware remains the most effective mitigation."

Security researcher Justin O'Leary says Google initially accepted his Config Connector privilege-escalation report as a high-priority, high-severity bug, then denied a bounty by declaring the behavior "working as intended." According to The Register, a Google rep initially praised O'Leary's report with a "Nice catch!" before the cloud giant reversed course, declaring that no vulnerability existed and therefore no fix or reward was warranted. "The bug report, however, is still marked high-priority and accepted," the publication notes. The alleged flaw, dubbed ConfigConfusion, could let a Kubernetes namespace user exploit an overprivileged service account to become a GCP organization owner with only a few lines of YAML and little apparent audit visibility. O'Leary details the incident in a blog post. The Register reports: According to O'Leary, Config Connector doesn't perform an authorization check, and this allows any Config Connector service account with org-level permissions to bypass Identity and Access Management (IAM) authorization and gain the highest level of control (roles/owner) to an entire GCP Organization -- the root node of all of a company's resources within Google Cloud. On March 27, a Google security engineer accepted O'Leary's report and told him: "Nice catch!" The employee said that they filed a bug based on O'Leary's report with the relevant product team and assured him the Chocolate Factory's security squad would work with relevant Google Cloud people to fix the flaw. "We'll work with the product team to ensure this issue is address. We'll let you know when the issue was fixed," the engineer said. "In the meantime, review the payment option selected in your bughunters.google.com profile."

Google assigned the bug P1 priority and S1 severity, signifying a flaw worthy of urgent repair because it affects a large percentage of users and can disrupt core organizational functions. "I figured that was the end of that," O'Leary said in a phone interview with The Register. Eleven days later, on April 7, he received a new message from a Google Security Bot reversing the earlier decision. The Reg viewed the email, and O'Leary included a screenshot in his Thursday writeup. The message said that the Cloud Vulnerability Reward Program panel decided that the "security impact of this issue does not meet the criteria to qualify for a reward."

After reviewing the bug report, Google determined the software "is working as intended," the message continued. It also noted that the program's decision not to pay a bounty "does not mean that the product team won't fix the issue." Nearly three months later, the case remains P1/S1 with the status "in progress (accepted)." Google hasn't assigned a CVE or issued a fix. O'Leary didn't receive any reward for his research. [...] "This is a pattern," O'Leary told [The Register]. "This is just how these trillion-dollar companies deal with people like me. In my day job, we use GKE, and it's incredibly frustrating on my end, when I find a critical vulnerability in the system that's being widely used, and I can't even get the vendor to patch their own stuff." A Google spokesperson told The Register: "The issue reported does not qualify for a reward because the GCP IAM authorization bypass is only exploitable if an attacker has access to a Config Connector Service Account that's been granted the Organization Admin role by the organization (i.e., it is privileged). Additionally, an attacker would first need to gain entry to an organization's environment (e.g., an exposed container) in order to leverage the privileged Config Connector instance and execute commands with administrative authority, such as the IAM bypass. Granting this level of access to the Config Connector Service Account goes against Google Cloud's publicly shared best practices and the principle of least privilege."

An anonymous reader quotes a report from TechCrunch: A group made up of dozens of cybersecurity experts, including several well-known veterans of the industry, published an open letter to the U.S. government asking it to lift the export control order on Anthropic's Fable and Mythos models. According to the open letter, "this action has taken the best models away from [cybersecurity] defenders" who now can't use the models to find vulnerabilities and make their software and products more secure. "To pull the best capabilities away from defenders without a good reason when our adversaries are rapidly advancing is dangerous," read the letter.

On Friday, the U.S. government ordered Anthropic to limit the export of Fable and Mythos, citing national security concerns, without explaining the specific reasons behind the order, according to Anthropic. In response, the company suspended access to the models to all users worldwide. As of this writing, the letter is signed by 76 cybersecurity experts, including Alex Stamos, former Facebook chief of security; Casey Ellis, the founder bug bounty platform Bugcrowd; Jon Callas, famed cryptographer and former Apple security design and architecture manager; Paul Vixie, computer scientist ; Dino Dai Zovi, the former head of applied security engineering at Block; Katie Moussouris, the founder of Luta Security; and Rachel Tobac, the CEO of the security awareness training firm SocialProof Security.

[...] Anthropic said that the White House export control order may have been based on a report that there was a method to bypass -- or jailbreak -- Fable to unlock its powerful Mythos-level capabilities. According to Katie Moussouris, one of the signatories of the open letter, the method was demonstrated by Amazon researchers in a paper that is not public but that she has reviewed. But Moussouris said in a blog post that the paper did not actually demonstrate a real jailbreak. Instead, she wrote, the researchers simply asked Fable to fix open source code with public and known vulnerabilities along with "deliberately planted vulnerabilities," after the model initially refused to "review the code for security issues."

"The behavior described in the paper cannot meaningfully be fixed, and any attempt would only weaken the model for defense," Moussouris wrote. "Defenders need to be able to ask AI to fix the bugs in a file, explain why the fix matters, and write tests that confirm the patch works. That is not a guardrail bypass. It is the most valuable thing an AI model can do for defensive security: executing the find, fix, and test loop defenders run every day." Moussouris' critique was echoed in the open letter, which also said that the group of experts believe the model capabilities in the Amazon paper "can be replicated" on OpenAI's GPT-5.5, on Anthropic's own publicly available Claude Opus 4.8 and Sonnet, "and even Chinese models like Kimi 2.7."

Moussouris told TechCrunch that "the bugs used to demonstrate the techniques in the paper can be found using the other models. The method in the paper is a guardrail bypass technique. Other models that lack the Fable guardrails often won't refuse the straightforward request to look for security bugs, so they don't need a bypass." The letter also asked for transparently and fairly enforced regulations created by "a democratic rule-making process" that are based on scientific research done by industry and academic experts, and "used only to the minimal extent necessary to ensure the safety of the American public."

An anonymous reader quotes a report from Ars Technica: A decade ago, AMD added a protection to its high-end CPUs to protect them against cold boot attacks and other types of physical exploits that siphon sensitive data out of the connected memory chips. Short for Transparent Secure Memory Encryption, TSME encrypts the entire contents stored in memory, making the data useless to physical attackers. Over time, AMD added TSME to lower-end processors, including the consumer version of its Ryzen chips, a CPU that costs less than the Pro version. Over the years, users of these lower-end chips have gotten used to the added security. Recently and without warning or notice, this lower-end line of AMD chips suddenly dropped the protection, and did so in a way that was impossible to detect on Windows machines and required a fair amount of technical work when using Linux.

AMD has yet to say why TSME worked on these CPUs, or even to confirm the change. AMD declined to answer questions sent by email other than to say TSME "is a security feature only applied to PRO CPUs as part of AMD PRO Technologies." The statement is the first known time the chipmaker has explicitly made this restriction public. [...] There's no indication that AMD ever advertised or marketed TSME as being available in consumer CPUs. AMD has long said that a related memory protection, Secure Memory Encryption (SME), is available only in the Pro and Epyc CPU tiers. SME is OS-managed. It uses a single key and allows the OS to selectively encrypt individual memory pages. TSME is firmware-managed. It encrypts all RAM with no OS involvement. When active, it provides protection against physical attacks, including cold boot exploits, DRAM interface snooping, and memory module removal. It activates silently when enabled in the BIOS, making it the more practically useful of the two protections. Ben Kilpatrick, a self-described "privacy-conscious Linux hobbyist," discovered that TSME had stopped working on his consumer Ryzen processor despite remaining enabled in the BIOS. He spent months investigating, persuaded MSI engineers to test multiple CPUs, motherboards, and firmware versions, and filed a public AMD bug report that traced the change to newer AGESA firmware apparently disabling TSME on consumer chips while retaining it on Pro and EPYC models.

"AMD engineers' comments, such as those mentioned above, and the years of TSME working just fine in the lower-cost tier processors, have understandably conditioned Kilpatrick and other users to reasonably regard it as an expected part of the chip package," reports Ars Technica. "AMD quietly removing it and providing no acknowledgment or explanation strikes these users as something of a betrayal."

Joe Fitzgerald, an expert in silicon-level security, said in an interview: "They could have not realized they did it leading to their cagey responses, or they could have done it intentionally and tried to get away with it, leading to the same cagey responses. But I really feel like an explanation should be in order, even if it was 'TSME was never supposed to be supported. We did ship some firmwares that erroneously enabled it, but you shouldn't use them since we can't guarantee it'll work properly.'"

This month saw the release of Vim Classic 8.3, the first stable version of a new long-term support fork of Vim maintained without generative AI tools. Linuxiac reports: The release is based on Vim 8.2.0148 and includes selected bug fixes and patches backported from later upstream Vim releases. Vim Classic was first announced by [SourceHut's CEO/founder] Drew DeVault in March 2026 after he objected to LLM-assisted development in Vim and Neovim. In his announcement, DeVault said he no longer wanted to use software developed with LLM assistance and introduced Vim Classic as a fork for users who want to continue using Vim without that involvement... Vim Classic follows Vim's charityware model and continues to direct users toward Bram Moolenaar's long-running support for children in Uganda. The release is distributed as a signed source tarball from SourceHut, while future important announcements are expected through the project's mailing list.
"Vim is important to me..." DeVault wrote in March. (DeVault even tattooed "hjkl" on his right arm.) "[A]lmost every word I have ever committed to posterity, through this blog, in my code, all of the docs I've written, emails I've sent, and more, almost all of it has passed through Vim."

But DeVault wrote that he also cares about AI's impact on air pollution, fresh water supplies, global supply chains, and the working conditions of miners in African companies: And at a moment when the climate demands immediate action to reduce our footprint on this planet, the AI boom is driving data centers to consume a full 1.5% of the world's total energy production in order to eliminate jobs and replace them with a robot that lies... All this to enrich the few, centralize power, reduce competition, and underwrite an enormous bubble that, once it bursts, will ruin the lives of millions of the world's poor and marginalized classes.

I don't think it's cute that someone vibe coded "battleship" in VimScript. I think it's more important that we stop collectively pretending that we don't understand how awful all of this is. I don't want to use software which has slop in it. I do what I can to avoid it, and sadly even Vim now comes under scrutiny in that effort as both Vim and NeoVim are relying on LLMs to develop the software... To keep my conscience clear, and continue to enjoy the relationship I have with this amazing piece of software, I have forked Vim...

Since forking from this base, I have backported a handful of patches, most of which address CVEs discovered after this release, but others which address minor bug fixes. I also penned a handful of original patches which bring the codebase from this time up to snuff for building it on newer toolchains...

I invite you to use Vim Classic, if you feel the same way as me, and to maintain it with me, contributing the patches you need to support your own use cases.

Longtime Slashdot reader Dotnaught shares a report from The Register: For the past 90 days, Microsoft has been quietly patching a firmware flaw in Surface devices that allowed the hardware to be bricked with a single packet, though only for those who have disabled Secure Core and Secure Boot. And the company's Copilot AI software inadvertently helped identify the faulty firmware.

According to Jack Darcy, a security researcher based in Australia, his instance of Microsoft Copilot stumbled across the bug after being asked to adjust the screen backlighting on a Surface device. The Copilot-conjured Python script ended up rendering the researcher's laptop inoperable by overwriting the embedded controller firmware. "Copilot autonomously created and executed four progressively aggressive Python scripts during a probe for backlight control values that sent raw SSAM ioctl commands (SSAM_CDEV_REQUEST = 0xC028A501) directly to the SAM microcontroller through the SAM software path," Darcy explained to The Register.

[...] "We appreciate the work of Jack Darcy and The Register for reporting this issue under a coordinated vulnerability disclosure," a Microsoft spokesperson said in a statement. "Our investigation found that a deprecated UEFI interface could trigger a boot loop on some devices. To trigger this loop, the user must have administrator privileges and have already disabled the Secure Boot security feature. We have released updates to address the issue for most impacted devices."

That means managed devices are not at risk. But those using Linux, or Windows users who have disabled Secure Core and Secure Boot for gaming, or who use custom Windows drivers, or who have USB boot enabled, may still be vulnerable if their systems haven't received the update. We're uncertain about the range of Surface devices affected. Our source said it appears to be all of them (Surface Laptops 3-6, Surface Book 1-3) except for Surface Go models. ARM variants, however, have not been tested. The report notes that Microsoft is planning to move the Surface stack to a more secure architecture based on Rust code.

"Our most recent Surface for Business hardware features a major architectural shift in terms of improved reliability and security that spans our embedded controller, UEFI, but also some of our drivers," said David Abzarian, chief architect for Microsoft Surface. "We're investing in the most secure foundation for a PC by building our embedded controller firmware from the ground up in Rust (as part of leveraging and contributing to the Open Device Partnership (ODP)) in addition to a rewrite of the UEFI DXE Core in Rust; these projects are known as Secure EC and Project Patina respectively."

"We're also not only shipping some of our drivers written in Rust, but also helping co-develop the framework Windows Drivers in Rust (WDR) to help enable a broad set of partners in the Windows ecosystem to capitalize on these benefits. I will also note that all of these efforts are open-source promoting one of our key security principles around transparency."

The Asahi Linux team is warning Apple Silicon users not to upgrade to the macOS 27 beta because Apple's changes to the boot picker and Startup Disk app make Asahi partitions invisible, preventing Linux from booting. The Register reports: The team added: "If you insist on trying out macOS 27 as soon as possible, please ensure you install a secondary copy of macOS 26 first, or install macOS 27 itself on a secondary volume." They've also updated the installer to prevent installs from running on macOS 27 for now. For anyone who ignored all of the above, "we will not support users who have installed the macOS 27 beta without ensuring at least one stable version of macOS is installed."

Considering macOS 27 is in beta, the issue may be accidental rather than an attempt by Apple to block Linux on its hardware. The Asahi team said it has filed bug report. The good news for anyone who pulled the trigger on installing the macOS 27 beta is that although the partition might not be visible, it hasn't gone anywhere. The Asahi team wrote: "If you have already upgraded to the beta and noticed that your Asahi partition has disappeared, do not stress. Your Asahi partition is still there, and you have not lost any data."

An anonymous reader quotes a report from Ars Technica: Researchers have analyzed a high-severity vulnerability in Linux that's able to escalate untrusted users to root by exploiting a bug you don't often see: a single errant character inside the kernel. The vulnerability, tracked as CVE-2026-23111, is located in nf_tables, a subsystem of the Linux kernel that provides packet filtering capabilities. It's used to manage firewall rules and replaces older subsystems such as iptables, ip6tables, arptables, and ebtables.

The presence of a single mis-issued exclamation point in code implementing nf_tables introduced a use-after-free, a class of vulnerability that corrupts memory by placing malicious code at memory addresses that haven't been properly freed of their previous contents. CVE-2026-23111 can be exploited by an unprivileged user or process to elevate system rights to root. The exploit works by disrupting the deletion of verdicts -- a determination within the nf_tables framework that determines if a packet matches a rule calling for a certain action to be performed. This process can use what are known as catchall elements, which act as a wildcard in the event a lookup doesn't match any other element in the set.

When a verdict map is deleted from memory, catchall elements are deactivated and a chain's reference counter is decremented. When errors occur the deletion can be reversed and the counter incremented. CVE-2026-53111 allows for that process to be altered. As a result, the exploit can decrement the variable an arbitrary number of times and then delete and free the chain when some objects still point to it. Although the kernel vulnerability was fixed in February, multiple proof-of-concept exploits have since emerged, including one from FuzzingLabs in April and another from Exodus Intelligence that works on Debian and Ubuntu.

The Ladybird browser isn't opposed to AI coding tools, but it's just brought a new change to their code-contributing policies.

February 23: "Ladybird adopts Rust, with help from AI." Our first target was LibJS , Ladybirdâ(TM)s JavaScript engine... I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go... The requirement from the start was byte-for-byte identical output from both pipelines. The result was about 25,000 lines of Rust, and the entire port took about two weeks. The same work would have taken me multiple months to do by hand.
June 5 (Friday): We will no longer accept public pull requests... A pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds....

We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it. What has changed is how much faster and cheaper it has become to produce work that looks like a serious contribution... Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.

As part of this change, we will close all currently open public pull requests. We are grateful for the work people put into them, but keeping the existing queue open would keep that contribution path open in practice. There is no perfect time to make this change, so we are making it now. Going forward, pull requests will only be available to project maintainers. There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks...

Outside involvement still matters: clear bug reports, reductions, website testing, standards discussion, design discussion, security reports, and technical feedback all help move the project forward. This is the right change for Ladybird now. We are preparing to ship a browser to real users, and our development process has to match that responsibility.

Bitcoin briefly fell below $60,000 on Friday, "extending its weekly loss to nearly 20% and threatening to fall below $59,000," reports CoinDesk. Crypto was also hit by a 40%-plus plunge in Zcash after Shielded Labs disclosed a years-old bug that could have allowed undetected counterfeit ZEC creation. From the report: Now, with stocks in plunge mode -- the Nasdaq down nearly 4% on Friday -- bitcoin finds itself perfectly correlated. "Short term, Bitcoin feels like swallowing broken glass," wrote Jeff Swanson Friday. "The chart goes up. It goes down. It makes grown men cry into their Robinhood accounts and CNBC anchors smugly declare the funeral, for the eleventh time." "Here's what uncomfortable people don't understand: the discomfort is the yield. Every paper-handed panic seller is handing their future to someone with a longer time horizon and a colder storage device."

[...] Earlier, Shielded Labs, a nonprofit developer on the privacy token system, disclosed a critical vulnerability in Zcash's (ZEC) Orchard privacy pool that could have threatened the integrity of the token's supply. The vulnerability, if exploited, could have allowed an attacker to create an unlimited number of counterfeit ZEC tokens, completely undetected. "Think of it as someone secretly gaining access to the Federal Reserve's dollar printing press, except in this case, even the Fed wouldn't be able to tell these extra dollars were printed," wrote Omkar Godbole. Importantly, the vulnerability was discovered with help from Anthropic's recently released Opus 4.8 AI model, raising difficult questions for the entire crypto industry. More to come on that. ZEC is now down 42% over the past 24 hours. On Wednesday, the Zcash Foundation said: "The vulnerability was caught before any known exploitation occurred. There is no evidence of unauthorized value creation. Zcash's turnstile mechanism (which tracks the total ZEC balance across all value pools) confirmed that the total supply remained intact throughout. User privacy was not affected. Sapling and transparent transactions continued operating normally throughout the incident."

An anonymous reader quotes a report from The Guardian: Bumblebees can use tools to solve a problem, according to experiments that demonstrate their remarkably advanced cognitive abilities. The bees were given an adapted version of an experiment that, 100 years ago, first demonstrated chimpanzees could work out how to retrieve an out-of-reach banana by stacking boxes. Since then, various other primates, elephants and crows have joined an elite cohort of species known to be capable of this level of insight and spontaneous problem solving. In the latest research, bees were shown to be able to roll a polystyrene ball to a specific location and climb on to it in order to access an artificial flower on a low ceiling. The findings challenge the longstanding assumption that insects operate purely on instinct and mindless trial-and-error learning. "Most people think insects are reflex-based machines," said Dr Olli Loukola, a behavioral ecologist at the University of Oulu, Finland, and senior author. "That they can't have any emotional states or feel pain. Some people don't even realize that they have brains. I hope that these results change the worldview about that."

"We are not claiming that bees think like humans," added Loukola. "But our findings show that miniature brains can generate flexible solutions to novel problems in ways we are only beginning to understand."

The findings are published in the journal Science.

BrianFagioli writes: Fedora Linux 43 users upgrading to the latest Dovecot mail server discovered something rather unsettling: some older Microsoft Outlook configurations may have been silently ignoring SSL/TLS settings for POP3 email connections for years. According to a Fedora community blog post, affected Outlook clients reportedly continued using insecure port 110 connections even when encryption was enabled in the application settings. The issue surfaced after Dovecot 2.4 disabled plaintext authentication on non secure connections by default, causing Outlook users to suddenly lose mailbox access after the Fedora 43 upgrade.

The report suggests the behavior may date back as far as Outlook 2007, although modern Outlook builds were not fully tested. Fedora admins stress that the problem could be limited to legacy account configurations rather than current versions of Outlook itself. Still, the discovery has sparked discussion among Linux admins and security folks because many users likely assumed their email traffic was encrypted simply because Outlook claimed SSL/TLS was enabled. The incident also highlights how stricter defaults in modern open source infrastructure can expose ancient assumptions and questionable behaviors that quietly survived for decades.