group.of.nepali.translators team mailing list archive

[Mate Kukri <2055835@xxxxxxxxxxxxxxxxxx>]

This was fixed in debian sid already.

** Description changed:

+ [ Impact ]
+ 
+  * A large batch of secure boot CVEs in GRUB2 were fixed earlier this
+ year and recently un-embargoed earlier.
+ 
+  * This has an obvious impact on everyone relying on Secure Boot for any
+ purpose.
+ 
+ [ Test Plan ]
+ 
+  * In archive, ubuntu-boot-test in plucky, oracular, noble.
+    Local ubuntu-boot-test for jammy, focal.
+  
+  * Manual test boots of all revs on real hardware.
+ 
+ [ Where problems could occur ]
+ 
+  * While everything was previously tested, boot regressions are always possible.
+    We will watch the situation and quickly remedy anything asap.
+ 
+ ==============================================================================
+ This bug is being reused, but the original bug report is preserved below:
+ 
  Repeatedly executing the `insmod` command on a module leads to the
  module's reference count to be incremented on each execution.
  
  Unfortunately GRUB performs no overflow checks on module reference
  count, thus leading to the reference count overflowing, and in turn
  allowing `rrmod` to be executed on such a module.
  
  This returns the module's heap memory *while leaving active pointers to
  it*. Subsequent heap allocations will re-use this memory, potentially
  allowing an attacker to replace a module with an unsigned payload and
  lead to its execution.
  
  The reference count is a 32-bit integer, and executing enough `insmod`s
  to lead to it's overflow takes multiple hours thus making this issue
  exploit rather time consuming.

** Description changed:

  [ Impact ]
  
-  * A large batch of secure boot CVEs in GRUB2 were fixed earlier this
- year and recently un-embargoed earlier.
+  * A large batch of secure boot CVEs in GRUB2 were fixed earlier this
+ year and recently un-embargoed.
  
-  * This has an obvious impact on everyone relying on Secure Boot for any
+  * This has an obvious impact on everyone relying on Secure Boot for any
  purpose.
  
  [ Test Plan ]
  
-  * In archive, ubuntu-boot-test in plucky, oracular, noble.
-    Local ubuntu-boot-test for jammy, focal.
-  
-  * Manual test boots of all revs on real hardware.
+  * In archive, ubuntu-boot-test in plucky, oracular, noble.
+    Local ubuntu-boot-test for jammy, focal.
+ 
+  * Manual test boots of all revs on real hardware.
  
  [ Where problems could occur ]
  
-  * While everything was previously tested, boot regressions are always possible.
-    We will watch the situation and quickly remedy anything asap.
+  * While everything was previously tested, boot regressions are always possible.
+    We will watch the situation and quickly remedy anything asap.
  
  ==============================================================================
  This bug is being reused, but the original bug report is preserved below:
  
  Repeatedly executing the `insmod` command on a module leads to the
  module's reference count to be incremented on each execution.
  
  Unfortunately GRUB performs no overflow checks on module reference
  count, thus leading to the reference count overflowing, and in turn
  allowing `rrmod` to be executed on such a module.
  
  This returns the module's heap memory *while leaving active pointers to
  it*. Subsequent heap allocations will re-use this memory, potentially
  allowing an attacker to replace a module with an unsigned payload and
  lead to its execution.
  
  The reference count is a 32-bit integer, and executing enough `insmod`s
  to lead to it's overflow takes multiple hours thus making this issue
  exploit rather time consuming.

** Description changed:

+ Just to be clear this is now the tracking bug for all GRUB2 CVE fixes in
+ this batch, and not just the insmod refcount overflow it was originally
+ filed for.
+ 
  [ Impact ]
  
   * A large batch of secure boot CVEs in GRUB2 were fixed earlier this
  year and recently un-embargoed.
  
   * This has an obvious impact on everyone relying on Secure Boot for any
  purpose.
  
  [ Test Plan ]
  
   * In archive, ubuntu-boot-test in plucky, oracular, noble.
     Local ubuntu-boot-test for jammy, focal.
  
   * Manual test boots of all revs on real hardware.
  
  [ Where problems could occur ]
  
   * While everything was previously tested, boot regressions are always possible.
     We will watch the situation and quickly remedy anything asap.
  
  ==============================================================================
  This bug is being reused, but the original bug report is preserved below:
  
  Repeatedly executing the `insmod` command on a module leads to the
  module's reference count to be incremented on each execution.
  
  Unfortunately GRUB performs no overflow checks on module reference
  count, thus leading to the reference count overflowing, and in turn
  allowing `rrmod` to be executed on such a module.
  
  This returns the module's heap memory *while leaving active pointers to
  it*. Subsequent heap allocations will re-use this memory, potentially
  allowing an attacker to replace a module with an unsigned payload and
  lead to its execution.
  
  The reference count is a 32-bit integer, and executing enough `insmod`s
  to lead to it's overflow takes multiple hours thus making this issue
  exploit rather time consuming.

** Summary changed:

- insmod reference count overflow (GRUB 2025 spring security update)
+ GRUB 2025 spring security update

** Description changed:

  Just to be clear this is now the tracking bug for all GRUB2 CVE fixes in
  this batch, and not just the insmod refcount overflow it was originally
  filed for.
  
  [ Impact ]
  
   * A large batch of secure boot CVEs in GRUB2 were fixed earlier this
  year and recently un-embargoed.
  
   * This has an obvious impact on everyone relying on Secure Boot for any
  purpose.
  
  [ Test Plan ]
  
   * In archive, ubuntu-boot-test in plucky, oracular, noble.
     Local ubuntu-boot-test for jammy, focal.
  
   * Manual test boots of all revs on real hardware.
  
  [ Where problems could occur ]
  
   * While everything was previously tested, boot regressions are always possible.
     We will watch the situation and quickly remedy anything asap.
  
  ==============================================================================
  This bug is being reused, but the original bug report is preserved below:
  
  Repeatedly executing the `insmod` command on a module leads to the
  module's reference count to be incremented on each execution.
  
  Unfortunately GRUB performs no overflow checks on module reference
  count, thus leading to the reference count overflowing, and in turn
  allowing `rrmod` to be executed on such a module.
  
  This returns the module's heap memory *while leaving active pointers to
  it*. Subsequent heap allocations will re-use this memory, potentially
  allowing an attacker to replace a module with an unsigned payload and
  lead to its execution.
  
  The reference count is a 32-bit integer, and executing enough `insmod`s
- to lead to it's overflow takes multiple hours thus making this issue
- exploit rather time consuming.
+ that leads to overflow will take multiple hours thus making this issue
+ rather time consuming to exploit.

** Changed in: grub2-unsigned (Ubuntu Plucky)
       Status: New => Fix Committed

** Also affects: grub2-signed (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: grub2-signed (Ubuntu Plucky)
       Status: New => Fix Committed

** Changed in: grub2 (Ubuntu Plucky)
       Status: New => Fix Committed

** Changed in: grub2 (Ubuntu Noble)
       Status: New => Fix Committed

** Changed in: grub2 (Ubuntu Oracular)
       Status: New => Fix Committed

** Changed in: grub2-signed (Ubuntu Focal)
       Status: New => Fix Committed

** Changed in: grub2-signed (Ubuntu Jammy)
       Status: New => Fix Committed

** Changed in: grub2-signed (Ubuntu Noble)
       Status: New => Fix Committed

** Changed in: grub2-signed (Ubuntu Oracular)
       Status: New => Fix Committed

** Changed in: grub2-unsigned (Ubuntu Focal)
       Status: New => Fix Committed

** Changed in: grub2-unsigned (Ubuntu Jammy)
       Status: New => Fix Committed

** Changed in: grub2-unsigned (Ubuntu Noble)
       Status: New => Fix Committed

** Changed in: grub2-unsigned (Ubuntu Oracular)
       Status: New => Fix Committed

** No longer affects: grub2 (Debian)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/2055835

Title:
  GRUB 2025 spring security update

Status in grub2 package in Ubuntu:
  Fix Committed
Status in grub2-signed package in Ubuntu:
  Fix Committed
Status in grub2-unsigned package in Ubuntu:
  Fix Committed
Status in grub2 source package in Xenial:
  Invalid
Status in grub2-signed source package in Xenial:
  New
Status in grub2-unsigned source package in Xenial:
  New
Status in grub2 source package in Bionic:
  Invalid
Status in grub2-signed source package in Bionic:
  New
Status in grub2-unsigned source package in Bionic:
  New
Status in grub2 source package in Focal:
  Invalid
Status in grub2-signed source package in Focal:
  Fix Committed
Status in grub2-unsigned source package in Focal:
  Fix Committed
Status in grub2 source package in Jammy:
  Invalid
Status in grub2-signed source package in Jammy:
  Fix Committed
Status in grub2-unsigned source package in Jammy:
  Fix Committed
Status in grub2 source package in Noble:
  Fix Committed
Status in grub2-signed source package in Noble:
  Fix Committed
Status in grub2-unsigned source package in Noble:
  Fix Committed
Status in grub2 source package in Oracular:
  Fix Committed
Status in grub2-signed source package in Oracular:
  Fix Committed
Status in grub2-unsigned source package in Oracular:
  Fix Committed
Status in grub2 source package in Plucky:
  Fix Committed
Status in grub2-signed source package in Plucky:
  Fix Committed
Status in grub2-unsigned source package in Plucky:
  Fix Committed

Bug description:
  Just to be clear this is now the tracking bug for all GRUB2 CVE fixes
  in this batch, and not just the insmod refcount overflow it was
  originally filed for.

  [ Impact ]

   * A large batch of secure boot CVEs in GRUB2 were fixed earlier this
  year and recently un-embargoed.

   * This has an obvious impact on everyone relying on Secure Boot for
  any purpose.

  [ Test Plan ]

   * In archive, ubuntu-boot-test in plucky, oracular, noble.
     Local ubuntu-boot-test for jammy, focal.

   * Manual test boots of all revs on real hardware.

  [ Where problems could occur ]

   * While everything was previously tested, boot regressions are always possible.
     We will watch the situation and quickly remedy anything asap.

  ==============================================================================
  This bug is being reused, but the original bug report is preserved below:

  Repeatedly executing the `insmod` command on a module leads to the
  module's reference count to be incremented on each execution.

  Unfortunately GRUB performs no overflow checks on module reference
  count, thus leading to the reference count overflowing, and in turn
  allowing `rrmod` to be executed on such a module.

  This returns the module's heap memory *while leaving active pointers
  to it*. Subsequent heap allocations will re-use this memory,
  potentially allowing an attacker to replace a module with an unsigned
  payload and lead to its execution.

  The reference count is a 32-bit integer, and executing enough
  `insmod`s that leads to overflow will take multiple hours thus making
  this issue rather time consuming to exploit.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2055835/+subscriptions