Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Submission + - Preliminary report says fuel switches were cut off before Air India 787 crash

hcs_$reboot writes: A pair of switches that control the fuel supply to the engines were set to "cutoff" moments before the crash of Air India Flight 171, according to a preliminary report from India's Air Accident Investigation Bureau released early Saturday in India.

According to the report, data from the flight recorders show that the two fuel control switches were switched from the "run" position to "cutoff" shortly after takeoff. In the cockpit voice recording, one of the pilots can be heard asking the other "why did he cutoff," the report says, while "the other pilot responded that he did not do so."

Moments later, the report says, the fuel switches were returned to the "run" position. But by then, the plane had begun to lose thrust and altitude. Both the engines appeared to relight, according to investigators, but only one of them was able to begin generating thrust.

Submission + - NVIDIA warns your GPU may be vulnerable to Rowhammer attacks (nerds.xyz)

BrianFagioli writes: NVIDIA just put out a new security notice, and if youâ(TM)re running one of its powerful GPUs, you might want to pay attention. Researchers from the University of Toronto have shown that Rowhammer attacks, which are already known to affect regular DRAM, can now target GDDR6 memory on NVIDIAâ(TM)s high-end GPUs when ECC is not enabled.

They pulled this off using an A6000 card, and it worked because system-level ECC was turned off. Once it was switched on, the attack no longer worked. That tells you everything you need to know. ECC matters.

Rowhammer has been around for years. Itâ(TM)s one of those weird memory bugs where repeatedly accessing one row in RAM can cause bits to flip in another row. Until now, this was mostly a CPU memory problem. But this research shows it can also be a GPU problem, and that should make data center admins and workstation users pause for a second.

NVIDIA is not sounding an alarm so much as reminding everyone that protections are already in place, but only if youâ(TM)re using the hardware properly. The company recommends enabling ECC if your GPU supports it. That includes cards in the Blackwell, Hopper, Ada, and Ampere lines, along with others used in DGX, HGX, and Jetson systems. It also includes popular workstation cards like the RTX A6000.

Thereâ(TM)s also built-in On-Die ECC in certain newer memory types like GDDR7 and HBM3. If youâ(TM)re lucky enough to be using a card that has it, youâ(TM)re automatically protected to some extent, because OD-ECC canâ(TM)t be turned off. Itâ(TM)s always working in the background.

But letâ(TM)s be real. A lot of people skip ECC because it can impact performance or because theyâ(TM)re running a setup that doesnâ(TM)t make it obvious whether ECC is on or off. If youâ(TM)re not sure where you stand, itâ(TM)s time to check. NVIDIA suggests using tools like nvidia-smi or, if youâ(TM)re in a managed enterprise setup, working with your systemâ(TM)s BMC or Redfish APIs to verify settings.

Comment Re:"far too small to generate any lift"?? (Score 2) 106

According to @StigAviation in a comment at a Blancolirio video on YouTube there are several reasons for the RAT to deploy, none of them are good.

There’s actually more conditions

Here’s the full list.

  Loss of all engines
  Both engines are at less than minimum idle RPM (Revolutions Per Minute)
  Loss of all hydraulic power - left, right, and center systems detect low pressure
  Loss of all electrical power
  BPCU (Bus Power Control Unit) detects loss of power to C1 and C2 TRU (Transformer Rectifier Unit)s
  On approach, loss of all four EMP (Electric Motor Pump) hydraulic pressures and loss of either the left or right flight controls ACE (Actuator Control Electronics)
  Rotor burst on takeoff that causes loss of both PECS (Power Electronics Cooling System) primary cooling loops.

I have also seen that mechanics doing maintenance on the plane need to take precautions for it to not be deployed in case they test the system, but that's when it's on the ground and if it deploys it could hit someone in the head and that wouldn't be good.

Submission + - This overlooked Linux boot flaw defeats Secure Boot heres how to fix it (nerds.xyz)

BrianFagioli writes: Security researcher Alexander Moch of ERNW has uncovered a surprisingly effective method for bypassing Secure Boot protections on modern Linux systems. No, the vulnerability is not in the kernel or GRUB. Actually, it is in the initramfs, and it is hiding in plain sight.

Most hardening guides focus on well-known defenses like full disk encryption, password protected bootloaders, and Secure Boot. But few mention what happens if someone gets their hands on your laptop for just a few minutes. It turns out they can drop into a debug shell from the initramfs, modify it, and inject persistent malware all without ever touching the signed kernel or breaking Secure Boot.

On distributions like Ubuntu 25.04 and Fedora 42, repeatedly failing the password prompt for an encrypted root partition can trigger a debug shell. From there, Moch demonstrates how an attacker could use a USB drive with a few prepared scripts to chroot into the target system and modify the initramfs. A custom script can be inserted into the boot sequence that silently executes each time the system starts up.

The problem stems from the fact that the initramfs is not typically signed. While the kernel and its modules are signed for Secure Boot compliance, the initramfs remains unsigned because it is generated locally and tailored to the host. That makes it easy to modify with no alarms going off.

Itâ(TM)s worth mentioning, this is not a totally new attack. It echoes CVE 2016 4484 and similar techniques like EvilAbigail1 from 2015 and de LUKS2 from 2018, but it is still widely effective today. The attack was tested on modern distributions using default encrypted configurations, including systems with Secure Boot enabled. While some distributions like OpenSuSE Tumbleweed encrypt the boot partition by default and are more resilient, most others including Ubuntu are vulnerable out of the box.

Hardening tools like Lynis and even the CIS Benchmarks for Ubuntu and Red Hat do not mention this risk. NIST STIGs are also silent on the matter.

The fix is shockingly simple.

On Ubuntu, just add panic=0 to your kernel parameters. On Red Hat based systems, use rd.shell=0 rd.emergency=halt. This prevents the system from dropping into a debug shell during boot failures. Beyond that, users can require a bootloader password for every boot, not just when editing entries. Encrypting the boot partition with LUKS or enabling the SSDâ(TM)s built in encryption are other solid steps.

Longer term solutions include using Unified Kernel Images which bundle and sign the kernel and initramfs together, or relying on TPMs to measure boot components. But those are not fully rolled out yet across the Linux ecosystem.

Mochâ(TM)s full writeup includes proof of concept scripts and step by step instructions for modifying the initramfs once access to the debug shell is gained. While his demo uses a harmless timestamp writing script as an example, the same method could be used for far more serious attacks.

Submission + - Ingram Micro admits ransomware attack is disrupting orders and systems (nerds.xyz)

BrianFagioli writes: Ingram Micro is facing a serious disruption after discovering ransomware on parts of its internal systems. The tech distributor confirmed the cyberattack today and says itâ(TM)s working to restore operations as quickly as possible.

Here is the full statement issued by the company:

âoeIngram Micro recently identified ransomware on certain of its internal systems. Promptly after learning of the issue, the Company took steps to secure the relevant environment, including proactively taking certain systems offline and implementing other mitigation measures. The Company also launched an investigation with the assistance of leading cybersecurity experts and notified law enforcement.

Ingram Micro is working diligently to restore the affected systems so that it can process and ship orders, and the Company apologizes for any disruption this issue is causing its customers, vendor partners, and others.â
At the moment, Ingram Micro has not disclosed who is behind the attack or whether any customer or partner data was exposed. But by taking systems offline, the company is clearly prioritizing containment and recovery over speed.

Ransomware incidents like this continue to plague the tech industry, and for a company like Ingram Micro that plays a key role in global supply chains, even temporary outages can have wide-reaching effects.

If you rely on Ingram Micro for products or services, expect delays while the company works to get its systems back online.

Submission + - Cloudflare Begins "Pay Per Crawl" (businessinsider.com) 1

joshuark writes: Cloudflare will block Big Tech AI bot crawlers; the Pay Per Crawl lets creators charge AI giants for content access.
The moves address concerns about Big Tech exploiting content without consent or payment--a shift that could reshape the dynamics between content creators and AI companies. The company will automatically block AI crawlers from scraping the websites it powers, unless site owners explicitly opt in.

"Original content is what makes the internet one of the greatest inventions in the last century, and we have to come together to protect it," Cloudflare CEO Matthew Prince said.

Cloudflare hopes to create a transparent, consent-driven marketplace that helps creators decide whether to allow all AI crawlers, permit specific ones, or set their own access fees, turning previously unmonetized content usage into new revenue streams.

Slashdot Top Deals

With all the fancy scientists in the world, why can't they just once build a nuclear balm?

Working...