--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/widget/gtk/nsDragService.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/widget/gtk/nsDragService.cpp@@ -49,10 +49,6 @@ #include "ScreenHelperGTK.h" #include "nsArrayUtils.h" #include "nsStringStream.h"-#ifdef MOZ_WAYLAND-#  include "nsClipboardWayland.h"-#  include "gfxPlatformGtk.h"-#endif #include "nsDirectoryService.h" #include "nsDirectoryServiceDefs.h" #include "nsEscape.h"@@ -125,13 +121,7 @@     : mScheduledTask(eDragTaskNone),       mTaskSource(0),       mScheduledTaskIsRunning(false),-      mCachedDragContext()-#ifdef MOZ_WAYLAND-      ,-      mPendingWaylandDataOffer(nullptr),-      mTargetWaylandDataOffer(nullptr)-#endif-{+      mCachedDragContext() {   // We have to destroy the hidden widget before the event loop stops   // running.   nsCOMPtr<nsIObserverService> obsServ =@@ -381,13 +371,11 @@   gtk_window_group_add_window(window_group, GTK_WINDOW(mHiddenWidget));   // Get device for event source-  GdkDisplay* display = gdk_display_get_default();-  GdkDeviceManager* device_manager = gdk_display_get_device_manager(display);-  event.button.device = gdk_device_manager_get_client_pointer(device_manager);+  event.button.device = widget::GdkGetPointer();   // start our drag.-  GdkDragContext* context =-      gtk_drag_begin(mHiddenWidget, sourceList, action, 1, &event);+  GdkDragContext* context = gtk_drag_begin_with_coordinates(+      mHiddenWidget, sourceList, action, 1, &event, -1, -1);   nsresult rv;   if (context) {@@ -530,9 +518,6 @@   // We're done with the drag context.   mTargetDragContextForRemote = nullptr;-#ifdef MOZ_WAYLAND-  mTargetWaylandDataOfferForRemote = nullptr;-#endif   mTargetWindow = nullptr;   mPendingWindow = nullptr;   mCachedDragContext = 0;@@ -662,11 +647,11 @@   for (GList* tmp = gdk_drag_context_list_targets(mTargetDragContext); tmp;        tmp = tmp->next) {     GdkAtom atom = GDK_POINTER_TO_ATOM(tmp->data);-    gchar* name = gdk_atom_name(atom);+    GUniquePtr<gchar> name(gdk_atom_name(atom));     if (!name) {       continue;     }-    aFlavors.AppendElement(nsCString(name));+    aFlavors.AppendElement(nsCString(name.get()));   } }@@ -890,13 +875,8 @@     }  // else we try one last ditch effort to find our data     if (dataFound) {-#if MOZ_LOGGING-      char* name = gdk_atom_name(gdkFlavor);-      if (name) {-        LOGDRAGSERVICE(("  actual data found %s\n", name));-        g_free(name);-      }-#endif+      LOGDRAGSERVICE(("  actual data found %s\n",+                      GUniquePtr<gchar>(gdk_atom_name(gdkFlavor)).get()));       if (flavorStr.EqualsLiteral(kJPEGImageMime) ||           flavorStr.EqualsLiteral(kJPGImageMime) ||@@ -991,38 +971,31 @@   if (mTargetDragContext) {     tmp = gdk_drag_context_list_targets(mTargetDragContext);   }-#ifdef MOZ_WAYLAND-  else if (mTargetWaylandDataOffer) {-    tmp = mTargetWaylandDataOffer->GetDragTargets();-  }-  GList* tmp_head = tmp;-#endif   for (; tmp; tmp = tmp->next) {     /* Bug 331198 */     GdkAtom atom = GDK_POINTER_TO_ATOM(tmp->data);-    gchar* name = nullptr;-    name = gdk_atom_name(atom);+    GUniquePtr<gchar> name(gdk_atom_name(atom));     if (!name) {       continue;     }-    if (strcmp(name, aDataFlavor) == 0) {+    if (strcmp(name.get(), aDataFlavor) == 0) {       *_retval = true;     }     // check for automatic text/uri-list -> text/x-moz-url mapping-    else if (strcmp(name, gTextUriListType) == 0 &&+    else if (strcmp(name.get(), gTextUriListType) == 0 &&              (strcmp(aDataFlavor, kURLMime) == 0 ||               strcmp(aDataFlavor, kFileMime) == 0)) {       *_retval = true;     }     // check for automatic _NETSCAPE_URL -> text/x-moz-url mapping-    else if (strcmp(name, gMozUrlType) == 0 &&+    else if (strcmp(name.get(), gMozUrlType) == 0 &&              (strcmp(aDataFlavor, kURLMime) == 0)) {       *_retval = true;     }     // check for auto text/plain -> text/unicode mapping-    else if (strcmp(name, kTextMime) == 0 &&+    else if (strcmp(name.get(), kTextMime) == 0 &&              ((strcmp(aDataFlavor, kUnicodeMime) == 0) ||               (strcmp(aDataFlavor, kFileMime) == 0))) {       *_retval = true;@@ -1030,18 +1003,9 @@     if (*_retval) {       LOGDRAGSERVICE(-          ("  supported, with converting %s => %s", name, aDataFlavor));-    }-    g_free(name);-  }--#ifdef MOZ_WAYLAND-  // mTargetWaylandDataOffer->GetDragTargets allocates the list-  // so we need to free it here.-  if (!mTargetDragContext && tmp_head) {-    g_list_free(tmp_head);-  }-#endif+          ("  supported, with converting %s => %s", name.get(), aDataFlavor));+    }+  }   if (!*_retval) {     LOGDRAGSERVICE(("  %s is not supported", aDataFlavor));@@ -1076,33 +1040,6 @@   gdk_drag_status(aDragContext, action, mTargetTime); }-#ifdef MOZ_WAYLAND-void nsDragService::ReplyToDragMotion(RefPtr<DataOffer> aDragContext) {-  LOGDRAGSERVICE(("nsDragService::ReplyToDragMotion %d", mCanDrop));--  GdkDragAction action = (GdkDragAction)0;-  if (mCanDrop) {-    // notify the dragger if we can drop-    switch (mDragAction) {-      case DRAGDROP_ACTION_COPY:-        action = GDK_ACTION_COPY;-        break;-      case DRAGDROP_ACTION_LINK:-        action = GDK_ACTION_LINK;-        break;-      case DRAGDROP_ACTION_NONE:-        action = (GdkDragAction)0;-        break;-      default:-        action = GDK_ACTION_MOVE;-        break;-    }-  }--  aDragContext->SetDragStatus(action);-}-#endif- void nsDragService::EnsureCachedDataValidForContext(     GdkDragContext* aDragContext) {   if (mCachedDragContext != (uintptr_t)aDragContext) {@@ -1126,9 +1063,8 @@   const guchar* data = gtk_selection_data_get_data(aSelectionData);   GdkAtom target = gtk_selection_data_get_target(aSelectionData);-  char* name = gdk_atom_name(target);-  nsCString flavor(name);-  g_free(name);+  GUniquePtr<gchar> name(gdk_atom_name(target));+  nsDependentCString flavor(name.get());   LOGDRAGSERVICE(("  got data, MIME %s", flavor.get()));@@ -1169,47 +1105,31 @@   if (mTargetDragContext) {     tmp = gdk_drag_context_list_targets(mTargetDragContext);   }-#ifdef MOZ_WAYLAND-  GList* tmp_head = nullptr;-  if (mTargetWaylandDataOffer) {-    tmp_head = tmp = mTargetWaylandDataOffer->GetDragTargets();-  }-#endif   // walk the list of context targets and see if one of them is a list   // of items.   for (; tmp; tmp = tmp->next) {     /* Bug 331198 */     GdkAtom atom = GDK_POINTER_TO_ATOM(tmp->data);-    gchar* name = nullptr;-    name = gdk_atom_name(atom);-    if (name && strcmp(name, gMimeListType) == 0) retval = true;-    g_free(name);-    if (retval) break;-  }--#ifdef MOZ_WAYLAND-  // mTargetWaylandDataOffer->GetDragTargets allocates the list-  // so we need to free it here.-  if (mTargetWaylandDataOffer && tmp_head) {-    g_list_free(tmp_head);-  }-#endif+    GUniquePtr<gchar> name(gdk_atom_name(atom));+    if (name && !strcmp(name.get(), gMimeListType)) {+      return true;+    }+  }   return retval; } void nsDragService::GetTargetDragData(GdkAtom aFlavor,                                       nsTArray<nsCString>& aDropFlavors) {-  LOGDRAGSERVICE(-      ("nsDragService::GetTargetDragData '%s'\n", gdk_atom_name(aFlavor)));+  LOGDRAGSERVICE(("nsDragService::GetTargetDragData '%s'\n",+                  GUniquePtr<gchar>(gdk_atom_name(aFlavor)).get()));   // reset our target data areas   TargetResetData();-  char* name = gdk_atom_name(aFlavor);-  nsCString flavor(name);-  g_free(name);+  GUniquePtr<gchar> name(gdk_atom_name(aFlavor));+  nsDependentCString flavor(name.get());   // Return early when requested MIME is not offered by D&D.   if (!aDropFlavors.Contains(flavor)) {@@ -1255,13 +1175,6 @@       gtk_main_iteration();     }   }-#ifdef MOZ_WAYLAND-  else if (mTargetWaylandDataOffer) {-    mTargetDragData = mTargetWaylandDataOffer->GetDragData(-        gdk_atom_name(aFlavor), &mTargetDragDataLen);-    mTargetDragDataReceived = true;-  }-#endif #ifdef MOZ_LOGGING   if (mTargetDragDataLen && mTargetDragData) {@@ -1423,12 +1336,13 @@     // We don't have a drag end point, so guess     gint x, y;     GdkDisplay* display = gdk_display_get_default();-    if (display) {-      gint scale = mozilla::widget::ScreenHelperGTK::GetGTKMonitorScaleFactor();-      gdk_display_get_pointer(display, nullptr, &x, &y, nullptr);-      SetDragEndPoint(LayoutDeviceIntPoint(x * scale, y * scale));-      LOGDRAGSERVICE(("guess drag end point %d %d\n", x * scale, y * scale));-    }+    GdkScreen* screen = gdk_display_get_default_screen(display);+    GdkWindow* window = gdk_screen_get_root_window(screen);+    gdk_window_get_device_position(window, widget::GdkGetPointer(), &x, &y,+                                   nullptr);+    gint scale = mozilla::widget::ScreenHelperGTK::GetGTKMonitorScaleFactor();+    SetDragEndPoint(LayoutDeviceIntPoint(x * scale, y * scale));+    LOGDRAGSERVICE(("guess drag end point %d %d\n", x * scale, y * scale));   }   // Either the drag was aborted or the drop occurred outside the app.@@ -1473,8 +1387,7 @@   }   // Schedule the appropriate drag end dom events.-  Schedule(eDragTaskSourceEnd, nullptr, nullptr, nullptr,-           LayoutDeviceIntPoint(), 0);+  Schedule(eDragTaskSourceEnd, nullptr, nullptr, LayoutDeviceIntPoint(), 0); } static void CreateURIList(nsIArray* aItems, nsACString& aURIList) {@@ -1712,14 +1625,13 @@                                   guint32 aTime) {   LOGDRAGSERVICE(("nsDragService::SourceDataGet"));   GdkAtom target = gtk_selection_data_get_target(aSelectionData);-  gchar* typeName = gdk_atom_name(target);+  GUniquePtr<gchar> typeName(gdk_atom_name(target));   if (!typeName) {     LOGDRAGSERVICE(("  failed to get atom name.\n"));     return;   }-  LOGDRAGSERVICE(("  Type is %s\n", typeName));-  auto freeTypeName = mozilla::MakeScopeExit([&] { g_free(typeName); });+  LOGDRAGSERVICE(("  Type is %s\n", typeName.get()));   // check to make sure that we have data items to return.   if (!mSourceDataItems) {     LOGDRAGSERVICE(("  Failed to get our data items\n"));@@ -1743,27 +1655,27 @@   bool needToDoConversionToPlainText = false;   bool needToDoConversionToImage = false;-  nsDependentCSubstring mimeFlavor(typeName, strlen(typeName));-  const char* actualFlavor;+  nsDependentCString mimeFlavor(typeName.get());+  const char* actualFlavor = nullptr;   if (mimeFlavor.EqualsLiteral(kTextMime) ||       mimeFlavor.EqualsLiteral(gTextPlainUTF8Type)) {     actualFlavor = kUnicodeMime;     needToDoConversionToPlainText = true;-    LOGDRAGSERVICE(("  convert %s => %s", typeName, actualFlavor));+    LOGDRAGSERVICE(("  convert %s => %s", typeName.get(), actualFlavor));   }   // if someone was asking for _NETSCAPE_URL we need to convert to   // plain text but we also need to look for x-moz-url   else if (mimeFlavor.EqualsLiteral(gMozUrlType)) {     actualFlavor = kURLMime;     needToDoConversionToPlainText = true;-    LOGDRAGSERVICE(("  convert %s => %s", typeName, actualFlavor));+    LOGDRAGSERVICE(("  convert %s => %s", typeName.get(), actualFlavor));   }   // if someone was asking for text/uri-list we need to convert to   // plain text.   else if (mimeFlavor.EqualsLiteral(gTextUriListType)) {     actualFlavor = gTextUriListType;     needToDoConversionToPlainText = true;-    LOGDRAGSERVICE(("  convert %s => %s", typeName, actualFlavor));+    LOGDRAGSERVICE(("  convert %s => %s", typeName.get(), actualFlavor));     // The desktop or file manager expects for drags of promise-file data     // the text/uri-list flavor set to a temporary file that contains the@@ -1881,10 +1793,10 @@              mimeFlavor.EqualsLiteral(kGIFImageMime)) {     actualFlavor = kNativeImageMime;     needToDoConversionToImage = true;-    LOGDRAGSERVICE(("  convert %s => %s", typeName, actualFlavor));+    LOGDRAGSERVICE(("  convert %s => %s", typeName.get(), actualFlavor));   } else {-    actualFlavor = typeName;-    LOGDRAGSERVICE(("  use %s", typeName));+    actualFlavor = typeName.get();+    LOGDRAGSERVICE(("  use %s", typeName.get()));   }   nsresult rv;   nsCOMPtr<nsISupports> data;@@ -1946,7 +1858,7 @@   } else {     if (mimeFlavor.EqualsLiteral(gTextUriListType)) {       // fall back for text/uri-list-      LOGDRAGSERVICE(("  fall back to %s\n", typeName));+      LOGDRAGSERVICE(("  fall back to %s\n", typeName.get()));       nsAutoCString list;       CreateURIList(mSourceDataItems, list);       gtk_selection_data_set(aSelectionData, target, 8, (guchar*)list.get(),@@ -2087,8 +1999,8 @@     for (GList* tmp = gdk_drag_context_list_targets(aContext); tmp;          tmp = tmp->next) {       GdkAtom atom = GDK_POINTER_TO_ATOM(tmp->data);-      gchar* name = gdk_atom_name(atom);-      if (name && (strcmp(name, gTabDropType) == 0)) {+      GUniquePtr<gchar> name(gdk_atom_name(atom));+      if (name && !strcmp(name.get(), gTabDropType)) {         aResult = MOZ_GTK_DRAG_RESULT_NO_TARGET;         LOGDRAGSERVICE(("invisibleSourceDragFailed: Wayland tab drop\n"));         break;@@ -2161,7 +2073,6 @@ gboolean nsDragService::ScheduleMotionEvent(nsWindow* aWindow,                                             GdkDragContext* aDragContext,-                                            RefPtr<DataOffer> aWaylandDataOffer,                                             LayoutDeviceIntPoint aWindowPoint,                                             guint aTime) {   if (aDragContext && mScheduledTask == eDragTaskMotion) {@@ -2175,27 +2086,23 @@   // Returning TRUE means we'll reply with a status message, unless we first   // get a leave.-  return Schedule(eDragTaskMotion, aWindow, aDragContext, aWaylandDataOffer,-                  aWindowPoint, aTime);+  return Schedule(eDragTaskMotion, aWindow, aDragContext, aWindowPoint, aTime); } void nsDragService::ScheduleLeaveEvent() {   // We don't know at this stage whether a drop signal will immediately   // follow.  If the drop signal gets sent it will happen before we return   // to the main loop and the scheduled leave task will be replaced.-  if (!Schedule(eDragTaskLeave, nullptr, nullptr, nullptr,-                LayoutDeviceIntPoint(), 0)) {+  if (!Schedule(eDragTaskLeave, nullptr, nullptr, LayoutDeviceIntPoint(), 0)) {     NS_WARNING("Drag leave after drop");   } } gboolean nsDragService::ScheduleDropEvent(nsWindow* aWindow,                                           GdkDragContext* aDragContext,-                                          RefPtr<DataOffer> aWaylandDataOffer,                                           LayoutDeviceIntPoint aWindowPoint,                                           guint aTime) {-  if (!Schedule(eDragTaskDrop, aWindow, aDragContext, aWaylandDataOffer,-                aWindowPoint, aTime)) {+  if (!Schedule(eDragTaskDrop, aWindow, aDragContext, aWindowPoint, aTime)) {     NS_WARNING("Additional drag drop ignored");     return FALSE;   }@@ -2218,7 +2125,6 @@ gboolean nsDragService::Schedule(DragTask aTask, nsWindow* aWindow,                                  GdkDragContext* aDragContext,-                                 RefPtr<DataOffer> aWaylandDataOffer,                                  LayoutDeviceIntPoint aWindowPoint,                                  guint aTime) {   // If there is an existing leave or motion task scheduled, then that@@ -2243,9 +2149,6 @@   mScheduledTask = aTask;   mPendingWindow = aWindow;   mPendingDragContext = aDragContext;-#ifdef MOZ_WAYLAND-  mPendingWaylandDataOffer = aWaylandDataOffer;-#endif   mPendingWindowPoint = aWindowPoint;   mPendingTime = aTime;@@ -2336,9 +2239,6 @@                   mTargetWindow.get(), mTargetWidget.get()));   mTargetDragContext = std::move(mPendingDragContext);-#ifdef MOZ_WAYLAND-  mTargetWaylandDataOffer = std::move(mPendingWaylandDataOffer);-#endif   mTargetTime = mPendingTime;   // http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#drag-and-drop-processing-model@@ -2371,9 +2271,6 @@     if (task == eDragTaskMotion) {       if (TakeDragEventDispatchedToChildProcess()) {         mTargetDragContextForRemote = mTargetDragContext;-#ifdef MOZ_WAYLAND-        mTargetWaylandDataOfferForRemote = mTargetWaylandDataOffer;-#endif       } else {         // Reply to tell the source whether we can drop and what         // action would be taken.@@ -2403,9 +2300,6 @@   LOGDRAGSERVICE(("  clear mTargetWindow mTargetWidget and other data\n"));   mTargetWidget = nullptr;   mTargetDragContext = nullptr;-#ifdef MOZ_WAYLAND-  mTargetWaylandDataOffer = nullptr;-#endif   // If we got another drag signal while running the sheduled task, that   // must have happened while running a nested event loop.  Leave the task@@ -2438,11 +2332,6 @@   if (mTargetDragContext) {     gdkAction = gdk_drag_context_get_actions(mTargetDragContext);   }-#ifdef MOZ_WAYLAND-  else if (mTargetWaylandDataOffer) {-    gdkAction = mTargetWaylandDataOffer->GetAvailableDragActions();-  }-#endif   // set the default just in case nothing matches below   if (gdkAction & GDK_ACTION_DEFAULT)@@ -2472,12 +2361,6 @@     ReplyToDragMotion(mTargetDragContextForRemote);     mTargetDragContextForRemote = nullptr;   }-#ifdef MOZ_WAYLAND-  else if (mTargetWaylandDataOfferForRemote) {-    ReplyToDragMotion(mTargetWaylandDataOfferForRemote);-    mTargetWaylandDataOfferForRemote = nullptr;-  }-#endif   return NS_OK; }@@ -2485,11 +2368,6 @@   if (mTargetDragContext) {     ReplyToDragMotion(mTargetDragContext);   }-#ifdef MOZ_WAYLAND-  else if (mTargetWaylandDataOffer) {-    ReplyToDragMotion(mTargetWaylandDataOffer);-  }-#endif } void nsDragService::DispatchMotionEvents() {

I'll analyze the code diff for security fixes following the specified format.

Vulnerability Existed: yes
Memory Leak Vulnerability [File] widget/gtk/nsDragService.cpp [Lines 662-647]
Old Code:
    gchar* name = gdk_atom_name(atom);
    if (!name) {
      continue;
    }
    aFlavors.AppendElement(nsCString(name));
Fixed Code:
    GUniquePtr<gchar> name(gdk_atom_name(atom));
    if (!name) {
      continue;
    }
    aFlavors.AppendElement(nsCString(name.get()));

Vulnerability Existed: yes
Memory Leak Vulnerability [File] widget/gtk/nsDragService.cpp [Lines 890-875]
Old Code:
    char* name = gdk_atom_name(gdkFlavor);
    if (name) {
      LOGDRAGSERVICE(("  actual data found %s\n", name));
      g_free(name);
    }
Fixed Code:
    LOGDRAGSERVICE(("  actual data found %s\n",
                  GUniquePtr<gchar>(gdk_atom_name(gdkFlavor)).get()));

Vulnerability Existed: yes
Memory Leak Vulnerability [File] widget/gtk/nsDragService.cpp [Lines 971-991]
Old Code:
    gchar* name = nullptr;
    name = gdk_atom_name(atom);
    if (!name) {
      continue;
    }
    [...]
    g_free(name);
Fixed Code:
    GUniquePtr<gchar> name(gdk_atom_name(atom));
    if (!name) {
      continue;
    }

Vulnerability Existed: yes
Memory Leak Vulnerability [File] widget/gtk/nsDragService.cpp [Lines 1125-1126]
Old Code:
    char* name = gdk_atom_name(target);
    nsCString flavor(name);
    g_free(name);
Fixed Code:
    GUniquePtr<gchar> name(gdk_atom_name(target));
    nsDependentCString flavor(name.get());

Vulnerability Existed: yes
Memory Leak Vulnerability [File] widget/gtk/nsDragService.cpp [Lines 1129-1130]
Old Code:
    char* name = gdk_atom_name(aFlavor);
    nsCString flavor(name);
    g_free(name);
Fixed Code:
    GUniquePtr<gchar> name(gdk_atom_name(aFlavor));
    nsDependentCString flavor(name.get());

Vulnerability Existed: yes
Memory Leak Vulnerability [File] widget/gtk/nsDragService.cpp [Lines 1625-1627]
Old Code:
    gchar* typeName = gdk_atom_name(target);
    [...]
    auto freeTypeName = mozilla::MakeScopeExit([&] { g_free(typeName); });
Fixed Code:
    GUniquePtr<gchar> typeName(gdk_atom_name(target));

The main security fixes in this diff address multiple memory leak vulnerabilities where gdk_atom_name() allocated strings weren't being properly freed. The fixes consistently use GUniquePtr to manage these allocations, ensuring automatic cleanup. This pattern is applied throughout the file wherever gdk_atom_name() is called.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.hsla-1.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.hsla-1.worker.js@@ -13,14 +13,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'hsla(120, 100%, 50%, 0.499)'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,127, "50,25", "0,255,0,127");+_assertPixel(canvas, 50,25, 0,255,0,127, "50,25", "0,255,0,127"); t.done(); });

Based on the provided diff, I'll analyze it for security vulnerabilities:

1. Vulnerability Existed: no
    No security vulnerability found [File] [Lines 13-14, 20]
    [Old Code]
    var offscreenCanvas = new OffscreenCanvas(100, 50);
    var ctx = offscreenCanvas.getContext('2d');
    _assertPixel(offscreenCanvas, 50,25, 0,255,0,127, "50,25", "0,255,0,127");
    
    [Fixed Code]
    var canvas = new OffscreenCanvas(100, 50);
    var ctx = canvas.getContext('2d');
    _assertPixel(canvas, 50,25, 0,255,0,127, "50,25", "0,255,0,127");

The changes appear to be purely cosmetic/refactoring, renaming the variable from `offscreenCanvas` to `canvas`. There are no security-related changes in this diff. The functionality remains exactly the same, just with a different variable name. No security vulnerability is being fixed here.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.moveTo.multiple.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.moveTo.multiple.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -29,7 +29,7 @@ ctx.strokeStyle = '#0f0'; ctx.lineWidth = 50; ctx.stroke();-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });

After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and don't involve any security-related modifications.

Here's the structured response:

    Vulnerability Existed: no
    No security vulnerability found [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.moveTo.multiple.html] [17-29]
    [Old Code]
    var offscreenCanvas = new OffscreenCanvas(100, 50);
    var ctx = offscreenCanvas.getContext('2d');
    ...
    _assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
    [Fixed Code]
    var canvas = new OffscreenCanvas(100, 50);
    var ctx = canvas.getContext('2d');
    ...
    _assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");

The changes are purely cosmetic/refactoring in nature and don't address any security issues. The functionality remains exactly the same, only the variable name has been changed for consistency or clarity.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/layout/xul/nsXULPopupManager.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/xul/nsXULPopupManager.h@@ -467,13 +467,25 @@   // will remain active.   void SetActiveMenuBar(nsMenuBarFrame* aMenuBar, bool aActivate);+  struct MayShowMenuResult {+    const bool mIsNative = false;+    nsMenuFrame* const mMenuFrame = nullptr;+    nsMenuPopupFrame* const mMenuPopupFrame = nullptr;++    explicit operator bool() const {+      MOZ_ASSERT(!!mMenuFrame == !!mMenuPopupFrame);+      return mIsNative || mMenuFrame;+    }+  };++  MayShowMenuResult MayShowMenu(nsIContent* aMenu);+   /**    * Open a <menu> given its content node. If aSelectFirstItem is    * set to true, the first item on the menu will automatically be-   * selected. If aAsynchronous is true, the event will be dispatched-   * asynchronously. This should be true when called from frame code.-   */-  void ShowMenu(nsIContent* aMenu, bool aSelectFirstItem, bool aAsynchronous);+   * selected.+   */+  void ShowMenu(nsIContent* aMenu, bool aSelectFirstItem);   /**    * Open a popup, either anchored or unanchored. If aSelectFirstItem is

Here's the analysis of the provided code diff following the specified format:

1. Vulnerability Existed: not sure
   [Potential Native Menu Handling Issue] [layout/xul/nsXULPopupManager.h] [Lines 467-478]
   [Old Code]
   - No explicit handling of native menu checks before showing menu
   [Fixed Code]
   + Added MayShowMenuResult struct and MayShowMenu function to explicitly handle native menu checks
   + Removed aAsynchronous parameter from ShowMenu

2. Vulnerability Existed: not sure
   [Potential Race Condition] [layout/xul/nsXULPopupManager.h] [Lines 479-482]
   [Old Code]
   void ShowMenu(nsIContent* aMenu, bool aSelectFirstItem, bool aAsynchronous);
   [Fixed Code]
   void ShowMenu(nsIContent* aMenu, bool aSelectFirstItem);

Notes:
- The changes introduce more rigorous menu showing checks through the new MayShowMenuResult struct and MayShowMenu function, which could potentially address security issues related to native menu handling.
- The removal of the aAsynchronous parameter might indicate fixing a potential race condition, but this is uncertain without more context.
- Without seeing the implementation of MayShowMenu or more context about the security implications, we can't definitively identify specific vulnerabilities, but these changes appear to be security-related improvements.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.invalid.rgba-3.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.invalid.rgba-3.worker.js@@ -13,14 +13,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0'; try { ctx.fillStyle = 'rgba(255, 0, 0, 1.)'; } catch (e) { } // this shouldn't throw, but it shouldn't matter here if it does ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });

Here's the analysis of the provided code diff:

1. Vulnerability Existed: no
   No specific vulnerability found [File] [Lines 13-14, 21]
   Old Code:
   ```javascript
   var offscreenCanvas = new OffscreenCanvas(100, 50);
   var ctx = offscreenCanvas.getContext('2d');
   _assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
   ```
   Fixed Code:
   ```javascript
   var canvas = new OffscreenCanvas(100, 50);
   var ctx = canvas.getContext('2d');
   _assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
   ```

The changes appear to be purely variable name changes from `offscreenCanvas` to `canvas` for consistency or readability. There's no indication of any security vulnerability being fixed in this diff. The test case itself remains functionally identical, just with a different variable name. The test still checks the same canvas behavior and pixel values.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/streams/ReadableStreamDefaultReader.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/streams/ReadableStreamDefaultReader.h@@ -23,6 +23,32 @@ class Promise; class ReadableStream;++// https://streams.spec.whatwg.org/#default-reader-read+struct Read_ReadRequest : public ReadRequest {+ public:+  NS_DECL_ISUPPORTS_INHERITED+  NS_DECL_CYCLE_COLLECTION_CLASS_INHERITED(Read_ReadRequest, ReadRequest)++  RefPtr<Promise> mPromise;+  /* This allows Gecko Internals to create objects with null prototypes, to hide+   * promise resolution from Object.prototype.then */+  bool mForAuthorCode = true;++  explicit Read_ReadRequest(Promise* aPromise, bool aForAuthorCode = true)+      : mPromise(aPromise), mForAuthorCode(aForAuthorCode) {}++  void ChunkSteps(JSContext* aCx, JS::Handle<JS::Value> aChunk,+                  ErrorResult& aRv) override;++  void CloseSteps(JSContext* aCx, ErrorResult& aRv) override;++  void ErrorSteps(JSContext* aCx, JS::Handle<JS::Value> e,+                  ErrorResult& aRv) override;++ protected:+  virtual ~Read_ReadRequest() = default;+}; class ReadableStreamDefaultReader final : public ReadableStreamGenericReader,                                           public nsWrapperCache@@ -69,6 +95,14 @@     JSContext* aCx, ReadableStreamDefaultReader* aReader,     ReadableStream* aStream, ErrorResult& aRv);+void ReadableStreamDefaultReaderErrorReadRequests(+    JSContext* aCx, ReadableStreamDefaultReader* aReader,+    JS::Handle<JS::Value> aError, ErrorResult& aRv);++void ReadableStreamDefaultReaderRelease(JSContext* aCx,+                                        ReadableStreamDefaultReader* aReader,+                                        ErrorResult& aRv);+ }  // namespace dom }  // namespace mozilla

Analyzing the provided code diff, I don't see any clear security vulnerabilities being fixed. The changes appear to be adding new functionality (a Read_ReadRequest class and some new functions) rather than fixing existing security issues.

Here's the analysis following your requested format:

Vulnerability Existed: no
No security vulnerability found [dom/streams/ReadableStreamDefaultReader.h] [Lines 23-95]
[Old code - none as this is an addition]
[Fixed Code - none as this is an addition]

The changes include:
1. Adding a new Read_ReadRequest class with promise handling functionality
2. Adding new functions for error handling and reader release
3. No modifications to existing security-sensitive code
4. No removal or modification of potentially vulnerable code

Since these are all additions of new code rather than modifications to existing code, there's no evidence of security vulnerabilities being addressed in this diff. The changes appear to be functional enhancements rather than security fixes.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/taskcluster/ci/toolchain/clang-tidy.yml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/taskcluster/ci/toolchain/clang-tidy.yml@@ -59,7 +59,7 @@         - trunk     fetches:         toolchain:-            - linux64-cctools-port-clang-13+            - linux64-cctools-port             - linux64-clang-13-macosx-cross             - macosx64-sdk-11.0@@ -82,7 +82,7 @@         - trunk     fetches:         toolchain:-            - linux64-cctools-port-clang-13+            - linux64-cctools-port             - linux64-clang-13-macosx-cross             - macosx64-sdk-11.0

Here's the analysis of the provided code diff:

1. Vulnerability Existed: not sure  
   [Potential Dependency Version Pinning Issue] [taskcluster/ci/toolchain/clang-tidy.yml] [Lines 59,82]  
   [Old Code]  
   `- linux64-cctools-port-clang-13`  
   [Fixed Code]  
   `- linux64-cctools-port`  
   Additional Details: The change removes the specific clang-13 version from the toolchain dependency. While this might not be a direct security vulnerability, it could potentially lead to version compatibility issues or using an unintended version of the toolchain if proper version pinning isn't handled elsewhere.

2. Vulnerability Existed: no  
   [No security vulnerability found] [taskcluster/ci/toolchain/clang-tidy.yml] [Lines 59,82]  
   [Old Code]  
   `- linux64-cctools-port-clang-13`  
   [Fixed Code]  
   `- linux64-cctools-port`  
   Additional Details: The change appears to be a simplification of the toolchain dependency name rather than a security fix. The modification doesn't show any clear security implications as it's likely an internal naming convention change.

Note: The diff shows identical changes in two locations (lines 59 and 82) with the same modification pattern. Without more context about the toolchain management system and version control practices, it's difficult to determine if this was an actual security fix or just a maintenance change.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.isPointInPath.outside.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.isPointInPath.outside.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.rect(0, -100, 20, 20); ctx.rect(20, -10, 20, 20);

Based on the provided code diff, here's the analysis:

Vulnerability Existed: no
[No security vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.isPointInPath.outside.worker.js] [Lines 13-14]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');

Additional Details:
The change appears to be a simple variable renaming from `offscreenCanvas` to `canvas`. This doesn't represent any security fix but rather a code style/consistency improvement. There are no security vulnerabilities being addressed in this diff.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/widget/cocoa/nsCocoaWindow.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/widget/cocoa/nsCocoaWindow.h@@ -264,9 +264,8 @@   virtual void PerformFullscreenTransition(FullscreenTransitionStage aStage, uint16_t aDuration,                                            nsISupports* aData, nsIRunnable* aCallback) override;   virtual void CleanupFullscreenTransition() override;-  nsresult MakeFullScreen(bool aFullScreen, nsIScreen* aTargetScreen = nullptr) final;-  nsresult MakeFullScreenWithNativeTransition(bool aFullScreen,-                                              nsIScreen* aTargetScreen = nullptr) final;+  nsresult MakeFullScreen(bool aFullScreen) final;+  nsresult MakeFullScreenWithNativeTransition(bool aFullScreen) final;   NSAnimation* FullscreenTransitionAnimation() const { return mFullscreenTransitionAnimation; }   void ReleaseFullscreenTransitionAnimation() {     MOZ_ASSERT(mFullscreenTransitionAnimation, "Should only be called when there is animation");

Let me analyze the provided code diff for security fixes:

Vulnerability Existed: not sure
[Potential Parameter Removal Vulnerability] [widget/cocoa/nsCocoaWindow.h] [Lines 264-268]
[Old Code]
nsresult MakeFullScreen(bool aFullScreen, nsIScreen* aTargetScreen = nullptr) final;
nsresult MakeFullScreenWithNativeTransition(bool aFullScreen,
                                          nsIScreen* aTargetScreen = nullptr) final;
[Fixed Code]
nsresult MakeFullScreen(bool aFullScreen) final;
nsresult MakeFullScreenWithNativeTransition(bool aFullScreen) final;

Additional Details:
The diff shows removal of the optional `nsIScreen* aTargetScreen` parameter from two methods. While this could potentially affect functionality, I cannot determine if this was specifically a security fix or just an API simplification. The removal of parameters could potentially close an attack vector if the screen parameter was previously being misused, but without more context about how these methods were used, I can't confirm a specific vulnerability.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.fillRect.shadow.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.fillRect.shadow.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -23,7 +23,7 @@ ctx.shadowOffsetX = 0; ctx.shadowOffsetY = 50; ctx.fillRect(0, -50, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });

Based on the provided diff, I'll analyze it for security vulnerabilities:

1. Vulnerability Existed: no
    No specific vulnerability found [File] [Lines 13-14, 23]
    [Old Code]
    var offscreenCanvas = new OffscreenCanvas(100, 50);
    var ctx = offscreenCanvas.getContext('2d');
    _assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
    
    [Fixed Code]
    var canvas = new OffscreenCanvas(100, 50);
    var ctx = canvas.getContext('2d');
    _assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");

The changes appear to be purely cosmetic/refactoring, renaming the variable from `offscreenCanvas` to `canvas` for consistency or readability. There are no security-related changes in this diff, no vulnerability patterns, and no changes to the actual functionality or security-relevant behavior of the code.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-hsl-5.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-hsl-5.worker.js@@ -13,14 +13,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'hsl(120deg, 100.0%, 50.0%, 0.2)'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51");+_assertPixel(canvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51"); t.done(); });

Based on the provided code diff, I'll analyze it for potential security vulnerabilities:

1. Vulnerability Existed: no
   No specific vulnerability found [File] [Lines 13-14, 20]
   [Old Code]
   var offscreenCanvas = new OffscreenCanvas(100, 50);
   var ctx = offscreenCanvas.getContext('2d');
   _assertPixel(offscreenCanvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51");
   
   [Fixed Code]
   var canvas = new OffscreenCanvas(100, 50);
   var ctx = canvas.getContext('2d');
   _assertPixel(canvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51");

Additional Details:
- The changes appear to be purely variable renaming (from 'offscreenCanvas' to 'canvas') and don't indicate any security fixes.
- The functionality remains identical, just with a different variable name.
- No security-related patterns (like input validation, sanitization, or security checks) were modified in this diff.
- This appears to be a code style/readability change rather than a security fix.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/devtools/server/actors/utils/inactive-property-helper.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/server/actors/utils/inactive-property-helper.js@@ -169,7 +169,6 @@           "row-gap",           // grid-*-gap are supported legacy shorthands for the corresponding *-gap properties.           // See https://drafts.csswg.org/css-align-3/#gap-legacy for more information.-          "grid-gap",           "grid-row-gap",         ],         when: () => !this.gridContainer && !this.flexContainer,@@ -195,6 +194,7 @@         invalidProperties: [           "column-gap",           "gap",+          "grid-gap",           // grid-*-gap are supported legacy shorthands for the corresponding *-gap properties.           // See https://drafts.csswg.org/css-align-3/#gap-legacy for more information.           "grid-column-gap",

Based on the provided code diff, I'll analyze it for security vulnerabilities:

1. Vulnerability Existed: no
    No specific vulnerability found [File] devtools/server/actors/utils/inactive-property-helper.js [Lines] 169-195
    [Old Code]
    Included "grid-gap" in first invalidProperties list
    [Fixed Code]
    Moved "grid-gap" to second invalidProperties list

Additional Details:
This appears to be a code reorganization/cleanup rather than a security fix. The change moves the "grid-gap" property from one invalid properties list to another, likely to better organize related CSS properties. There's no indication of a security vulnerability being fixed here - it's more about maintaining proper property categorization for CSS grid/flex layouts.

No CVE or specific vulnerability name is associated with this change, and the modification doesn't appear to address any security-related issue. The comment suggests it's related to CSS alignment specifications and legacy property handling.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.strokeRect.zero.4.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.strokeRect.zero.4.html@@ -17,14 +17,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.strokeStyle = '#f00'; ctx.lineWidth = 250; ctx.lineCap = 'round'; ctx.strokeRect(100, 25, 100, 0);-_assertPixel(offscreenCanvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0");+_assertPixel(canvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0"); t.done(); });

Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring (variable renaming) rather than security-related fixes. Here's the analysis:

    Vulnerability Existed: no
    No security vulnerability found [testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.strokeRect.zero.4.html] [Lines 17-25]
    [Old Code]
    var offscreenCanvas = new OffscreenCanvas(100, 50);
    var ctx = offscreenCanvas.getContext('2d');
    ...
    _assertPixel(offscreenCanvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0");
    [Fixed Code]
    var canvas = new OffscreenCanvas(100, 50);
    var ctx = canvas.getContext('2d');
    ...
    _assertPixel(canvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0");

The changes only involve renaming the variable `offscreenCanvas` to `canvas` and updating the references to it. There are no security implications in this change.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-shapes/shape-outside/assorted/float-retry-push-circle.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-shapes/shape-outside/assorted/float-retry-push-circle.html@@ -5,7 +5,6 @@ <link rel="author" title="Mozilla" href="http://www.mozilla.org/"> <link rel="help" href="https://drafts.csswg.org/css-shapes-1/"> <link rel="match" href="reference/float-retry-push-ref.html">-<meta name="flags" content=""> <meta name="assert" content="Test that a too-wide inline block is pushed in the block direction along a shape-outside circle until it fits."> <style>   body {

Analysis of the provided code diff:

1. Vulnerability Existed: no
   No specific vulnerability found [File] [Lines 5-6]
   [Old Code]
   <meta name="flags" content="">
   [Fixed Code]
   (removed line)

Additional Details:
- The diff shows removal of an empty meta "flags" tag, which doesn't appear to be security-related
- This appears to be a test file cleanup rather than a security fix
- No actual vulnerabilities or security-related changes were identified in this diff
- The change is likely related to test configuration rather than security hardening

Note: The file in question is a test file for CSS shape-outside functionality, and the change doesn't appear to address any security concerns. The modification is more likely related to test suite maintenance or cleanup.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/devtools/docs/contributor/tests/performance-tests-damp.md+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/docs/contributor/tests/performance-tests-damp.md@@ -48,7 +48,7 @@ ## How to run it on try? ```bash-./mach try fuzzy --query "'linux64-shippable/ 'damp" --rebuild 6+./mach try fuzzy --query "'test-linux1804-64-shippable-qr/ 'damp" --rebuild 6 ``` * Linux appears to build and run quickly, and offers quite stable results over the other OSes. The vast majority of performance issues for DevTools are OS agnostic, so it doesn't really matter which one you run them on.

Analysis of the provided code diff:

1. Vulnerability Existed: no
   No security vulnerability found [File] [Lines 48]
   [Old Code]
   ./mach try fuzzy --query "'linux64-shippable/ 'damp" --rebuild 6
   [Fixed Code]
   ./mach try fuzzy --query "'test-linux1804-64-shippable-qr/ 'damp" --rebuild 6

Additional Details:
- This appears to be a simple update to the test platform specification from "linux64-shippable" to "test-linux1804-64-shippable-qr"
- The change is related to test infrastructure and doesn't involve any security-sensitive components
- No security vulnerabilities are apparent in this change as it's just updating a test command parameter
- The modification seems to reflect an update in the testing environment naming convention rather than addressing any security issue

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/devtools/client/inspector/markup/test/browser_markup_scrollable_badge_click.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/inspector/markup/test/browser_markup_scrollable_badge_click.js@@ -21,12 +21,15 @@     .shift {         margin-left: 300px;     }+    .has-before::before {+      content: "-";+    }   </style>   <div id="top" class="parent">     <div id="child1" class="fixed shift">         <div id="child2" class="fixed"></div>     </div>-    <div id="child3" class="shift">+    <div id="child3" class="shift has-before">         <div id="child4" class="fixed"></div>     </div>   </div>

After analyzing the provided code diff, I don't see any security-related changes. The modifications appear to be purely cosmetic/functional changes to the test case's HTML structure and styling.

Here's the analysis following your requested format:

Vulnerability Existed: no
[No security vulnerability found] [devtools/client/inspector/markup/test/browser_markup_scrollable_badge_click.js] [Lines 21-29]
[Old Code]
    .shift {
        margin-left: 300px;
    }
  </style>
  <div id="top" class="parent">
    <div id="child1" class="fixed shift">
        <div id="child2" class="fixed"></div>
    </div>
    <div id="child3" class="shift">
[Fixed Code]
    .shift {
        margin-left: 300px;
    }
    .has-before::before {
      content: "-";
    }
  </style>
  <div id="top" class="parent">
    <div id="child1" class="fixed shift">
        <div id="child2" class="fixed"></div>
    </div>
    <div id="child3" class="shift has-before">

The changes consist of:
1. Adding a new CSS rule for `.has-before::before`
2. Adding the `has-before` class to the `child3` div

These are purely presentational changes with no security implications.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/security/manager/ssl/TransportSecurityInfo.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/security/manager/ssl/TransportSecurityInfo.cpp@@ -956,8 +956,8 @@   infoObject->mIsUntrusted = bits.mIsUntrusted; }-void TransportSecurityInfo::SetStatusErrorBits(nsNSSCertificate* cert,-                                               uint32_t collected_errors) {+void TransportSecurityInfo::SetStatusErrorBits(+    const nsCOMPtr<nsIX509Cert>& cert, uint32_t collected_errors) {   SetServerCert(cert, EVStatus::NotEV);   mHaveCertErrorBits = true;@@ -985,11 +985,7 @@   nsTArray<nsTArray<uint8_t>> certList = std::move(aCertList);   aOutput.Clear();   for (auto& certBytes : certList) {-    RefPtr<nsIX509Cert> cert = nsNSSCertificate::ConstructFromDER(-        BitwiseCast<char*, uint8_t*>(certBytes.Elements()), certBytes.Length());-    if (!cert) {-      return NS_ERROR_FAILURE;-    }+    RefPtr<nsIX509Cert> cert = new nsNSSCertificate(std::move(certBytes));     aOutput.AppendElement(cert);   }   return NS_OK;@@ -1011,8 +1007,8 @@   return NS_OK; }-void TransportSecurityInfo::SetServerCert(nsNSSCertificate* aServerCert,-                                          EVStatus aEVStatus) {+void TransportSecurityInfo::SetServerCert(+    const nsCOMPtr<nsIX509Cert>& aServerCert, EVStatus aEVStatus) {   MOZ_ASSERT(aServerCert);   MutexAutoLock lock(mMutex);

Analyzing the provided code diff, I can identify the following security-related changes:

1. First vulnerability fix:
    Vulnerability Existed: yes
    Improper Certificate Handling [File] [Lines 956-957, 1011-1012]
    [Old Code]
    void TransportSecurityInfo::SetStatusErrorBits(nsNSSCertificate* cert,
                                               uint32_t collected_errors)
    void TransportSecurityInfo::SetServerCert(nsNSSCertificate* aServerCert,
                                          EVStatus aEVStatus)
    [Fixed Code]
    void TransportSecurityInfo::SetStatusErrorBits(
        const nsCOMPtr<nsIX509Cert>& cert, uint32_t collected_errors)
    void TransportSecurityInfo::SetServerCert(
        const nsCOMPtr<nsIX509Cert>& aServerCert, EVStatus aEVStatus)
    Additional Details: The change from raw pointer to nsCOMPtr ensures proper reference counting and memory management of certificate objects, preventing potential use-after-free vulnerabilities.

2. Second vulnerability fix:
    Vulnerability Existed: yes
    Improper Certificate Construction [File] [Lines 985-991]
    [Old Code]
    RefPtr<nsIX509Cert> cert = nsNSSCertificate::ConstructFromDER(
        BitwiseCast<char*, uint8_t*>(certBytes.Elements()), certBytes.Length());
    if (!cert) {
      return NS_ERROR_FAILURE;
    }
    [Fixed Code]
    RefPtr<nsIX509Cert> cert = new nsNSSCertificate(std::move(certBytes));
    Additional Details: The new version uses safer certificate construction by moving the certificate bytes directly into the constructor rather than using potentially unsafe BitwiseCast and manual memory management. This prevents potential memory corruption issues.

Note that while these changes improve security, the exact vulnerabilities being fixed aren't explicitly named in the commit messages. The analysis is based on the security implications of the code changes.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/js/src/vm/StringType.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/vm/StringType.cpp@@ -25,6 +25,9 @@ #include "jsfriendapi.h" #include "builtin/Boolean.h"+#ifdef ENABLE_RECORD_TUPLE+#  include "builtin/RecordObject.h"+#endif #include "frontend/BytecodeCompiler.h" #include "gc/MaybeRooted.h" #include "gc/Nursery.h"@@ -925,7 +928,7 @@   if (MOZ_UNLIKELY(wholeLength > JSString::MAX_LENGTH)) {     // Don't report an exception if GC is not allowed, just return nullptr.     if (allowGC) {-      js::ReportAllocationOverflow(cx);+      js::ReportOversizedAllocation(cx, JSMSG_ALLOC_OVERFLOW);     }     return nullptr;   }@@ -1535,6 +1538,38 @@   return JSLinearString::new_<allowGC>(cx, std::move(news), n, heap); }+static MOZ_ALWAYS_INLINE JSInlineString* NewInlineStringForAtomDeflated(+    JSContext* cx, const char16_t* chars, size_t length) {+  Latin1Char* storage;+  JSInlineString* str = AllocateInlineStringForAtom(cx, length, &storage);+  if (!str) {+    return nullptr;+  }++  MOZ_ASSERT(CanStoreCharsAsLatin1(chars, length));+  FillFromCompatible(storage, chars, length);+  return str;+}++static JSLinearString* NewStringForAtomDeflatedValidLength(JSContext* cx,+                                                           const char16_t* s,+                                                           size_t n) {+  if (JSInlineString::lengthFits<Latin1Char>(n)) {+    return NewInlineStringForAtomDeflated(cx, s, n);+  }++  auto news = cx->make_pod_arena_array<Latin1Char>(js::StringBufferArena, n);+  if (!news) {+    cx->recoverFromOutOfMemory();+    return nullptr;+  }++  MOZ_ASSERT(CanStoreCharsAsLatin1(s, n));+  FillFromCompatible(news.get(), s, n);++  return JSLinearString::newForAtomValidLength(cx, std::move(news), n);+}+ template <AllowGC allowGC, typename CharT> JSLinearString* js::NewStringDontDeflate(     JSContext* cx, UniquePtr<CharT[], JS::FreePolicy> chars, size_t length,@@ -1608,28 +1643,44 @@ namespace js { template <AllowGC allowGC, typename CharT>+JSLinearString* NewStringCopyNDontDeflateNonStaticValidLength(+    JSContext* cx, const CharT* s, size_t n, gc::InitialHeap heap) {+  if (JSInlineString::lengthFits<CharT>(n)) {+    return NewInlineString<allowGC>(cx, mozilla::Range<const CharT>(s, n),+                                    heap);+  }++  auto news = cx->make_pod_arena_array<CharT>(js::StringBufferArena, n);+  if (!news) {+    if (!allowGC) {+      cx->recoverFromOutOfMemory();+    }+    return nullptr;+  }++  FillChars(news.get(), s, n);++  return JSLinearString::newValidLength<allowGC>(cx, std::move(news), n, heap);+}++template JSLinearString* NewStringCopyNDontDeflateNonStaticValidLength<CanGC>(+    JSContext* cx, const char16_t* s, size_t n, gc::InitialHeap heap);++template JSLinearString* NewStringCopyNDontDeflateNonStaticValidLength<CanGC>(+    JSContext* cx, const Latin1Char* s, size_t n, gc::InitialHeap heap);++template <AllowGC allowGC, typename CharT> JSLinearString* NewStringCopyNDontDeflate(JSContext* cx, const CharT* s,                                           size_t n, gc::InitialHeap heap) {   if (JSLinearString* str = TryEmptyOrStaticString(cx, s, n)) {     return str;   }-  if (JSInlineString::lengthFits<CharT>(n)) {-    return NewInlineString<allowGC>(cx, mozilla::Range<const CharT>(s, n),-                                    heap);-  }--  auto news = cx->make_pod_arena_array<CharT>(js::StringBufferArena, n);-  if (!news) {-    if (!allowGC) {-      cx->recoverFromOutOfMemory();-    }+  if (MOZ_UNLIKELY(!JSLinearString::validateLength(cx, n))) {     return nullptr;   }-  FillChars(news.get(), s, n);--  return JSLinearString::new_<allowGC>(cx, std::move(news), n, heap);+  return NewStringCopyNDontDeflateNonStaticValidLength<allowGC>(cx, s, n, heap); } template JSLinearString* NewStringCopyNDontDeflate<CanGC>(JSContext* cx,@@ -1684,6 +1735,54 @@ template JSLinearString* NewStringCopyN<NoGC>(JSContext* cx,                                               const Latin1Char* s, size_t n,                                               gc::InitialHeap heap);++template <typename CharT>+JSLinearString* NewStringForAtomCopyNDontDeflateValidLength(JSContext* cx,+                                                            const CharT* s,+                                                            size_t n) {+  if constexpr (std::is_same_v<CharT, char16_t>) {+    MOZ_ASSERT(!CanStoreCharsAsLatin1(s, n));+  }++  if (JSInlineString::lengthFits<CharT>(n)) {+    return NewInlineStringForAtom(cx, s, n);+  }++  auto news = cx->make_pod_arena_array<CharT>(js::StringBufferArena, n);+  if (!news) {+    cx->recoverFromOutOfMemory();+    return nullptr;+  }++  FillChars(news.get(), s, n);++  return JSLinearString::newForAtomValidLength(cx, std::move(news), n);+}++template JSLinearString* NewStringForAtomCopyNDontDeflateValidLength(+    JSContext* cx, const char16_t* s, size_t n);++template JSLinearString* NewStringForAtomCopyNDontDeflateValidLength(+    JSContext* cx, const Latin1Char* s, size_t n);++template <typename CharT>+JSLinearString* NewStringForAtomCopyNMaybeDeflateValidLength(JSContext* cx,+                                                             const CharT* s,+                                                             size_t n) {+  if constexpr (std::is_same_v<CharT, char16_t>) {+    if (CanStoreCharsAsLatin1(s, n)) {+      return NewStringForAtomDeflatedValidLength(cx, s, n);+    }+  }++  return NewStringForAtomCopyNDontDeflateValidLength(cx, s, n);+}++template JSLinearString* NewStringForAtomCopyNMaybeDeflateValidLength(+    JSContext* cx, const char16_t* s, size_t n);++template JSLinearString* NewStringForAtomCopyNMaybeDeflateValidLength(+    JSContext* cx, const Latin1Char* s, size_t n); JSLinearString* NewStringCopyUTF8N(JSContext* cx, const JS::UTF8Chars utf8,                                    gc::InitialHeap heap) {@@ -2115,15 +2214,17 @@     str = BigInt::toString<CanGC>(cx, i, 10);   } #ifdef ENABLE_RECORD_TUPLE-  else if (arg.isExtendedPrimitive()) {-    JSObject& obj = arg.toExtendedPrimitive();-    if (obj.is<js::TupleType>()) {-      str = js::TupleToSource(cx, &obj.as<js::TupleType>());-    } else if (obj.is<js::RecordType>()) {-      str = js::RecordToSource(cx, &obj.as<js::RecordType>());-    } else {-      MOZ_CRASH("Unsupported ExtendedPrimitive type");-    }+  else if (v.isExtendedPrimitive()) {+    if (!allowGC) {+      return nullptr;+    }+    if (IsTuple(v)) {+      Rooted<TupleType*> tup(cx, &TupleType::thisTupleValue(v));+      return TupleToSource(cx, tup);+    }+    Rooted<RecordType*> rec(cx);+    MOZ_ALWAYS_TRUE(RecordObject::maybeUnbox(&v.getObjectPayload(), &rec));+    return RecordToSource(cx, rec);   } #endif   else {

Analyzing the provided code diff, I'll identify potential security vulnerabilities following the specified format:

1. Vulnerability Existed: yes
Buffer Overflow Protection [js/src/vm/StringType.cpp] [Lines 925-928]
[Old Code]
    if (allowGC) {
      js::ReportAllocationOverflow(cx);
    }
[Fixed Code]
    if (allowGC) {
      js::ReportOversizedAllocation(cx, JSMSG_ALLOC_OVERFLOW);
    }
Additional Details: The change improves overflow handling by using a more specific error reporting function that includes a message about the allocation being oversized.

2. Vulnerability Existed: not sure
Memory Safety Improvements [js/src/vm/StringType.cpp] [Lines 1608-1643]
[Old Code]
(Previous implementation without length validation check)
[Fixed Code]
  if (MOZ_UNLIKELY(!JSLinearString::validateLength(cx, n))) {
    return nullptr;
  }
Additional Details: The addition of explicit length validation could prevent potential memory safety issues, though it's unclear if this was fixing a known vulnerability.

3. Vulnerability Existed: not sure
Extended Primitive Handling [js/src/vm/StringType.cpp] [Lines 2115-2214]
[Old Code]
    else if (arg.isExtendedPrimitive()) {
      JSObject& obj = arg.toExtendedPrimitive();
      if (obj.is<js::TupleType>()) {
        str = js::TupleToSource(cx, &obj.as<js::TupleType>());
      } else if (obj.is<js::RecordType>()) {
        str = js::RecordToSource(cx, &obj.as<js::RecordType>());
      } else {
        MOZ_CRASH("Unsupported ExtendedPrimitive type");
      }
    }
[Fixed Code]
    else if (v.isExtendedPrimitive()) {
      if (!allowGC) {
        return nullptr;
      }
      if (IsTuple(v)) {
        Rooted<TupleType*> tup(cx, &TupleType::thisTupleValue(v));
        return TupleToSource(cx, tup);
      }
      Rooted<RecordType*> rec(cx);
      MOZ_ALWAYS_TRUE(RecordObject::maybeUnbox(&v.getObjectPayload(), &rec));
      return RecordToSource(cx, rec);
    }
Additional Details: The changes improve handling of extended primitives with better memory management and error handling, but it's unclear if this was fixing a specific vulnerability.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/mozglue/misc/TimeStamp.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/mozglue/misc/TimeStamp.cpp@@ -36,7 +36,29 @@   TimeStampInitialization() {     TimeStamp::Startup();-    mFirstTimeStamp = TimeStamp::Now();+    TimeStamp now = TimeStamp::Now();++    TimeStamp process_creation;+    char* mozAppRestart = getenv("MOZ_APP_RESTART");++    /* When calling PR_SetEnv() with an empty value the existing variable may+     * be unset or set to the empty string depending on the underlying platform+     * thus we have to check if the variable is present and not empty. */+    if (mozAppRestart && (strcmp(mozAppRestart, "") != 0)) {+      process_creation = now;+    } else {+      uint64_t uptime = TimeStamp::ComputeProcessUptime();+      process_creation =+          now - TimeDuration::FromMicroseconds(static_cast<double>(uptime));++      if ((process_creation > now) || (uptime == 0)) {+        process_creation = now;+      }+    }++    mFirstTimeStamp = now;+    mProcessCreation = process_creation;+     // On Windows < 10, initializing the uptime requires `mFirstTimeStamp` to be     // valid.     mozilla::InitializeUptime();@@ -47,47 +69,12 @@ static TimeStampInitialization sInitOnce;-MFBT_API TimeStamp TimeStamp::ProcessCreation(bool* aIsInconsistent) {-  if (aIsInconsistent) {-    *aIsInconsistent = false;-  }--  if (sInitOnce.mProcessCreation.IsNull()) {-    char* mozAppRestart = getenv("MOZ_APP_RESTART");-    TimeStamp ts;--    /* When calling PR_SetEnv() with an empty value the existing variable may-     * be unset or set to the empty string depending on the underlying platform-     * thus we have to check if the variable is present and not empty. */-    if (mozAppRestart && (strcmp(mozAppRestart, "") != 0)) {-      /* Firefox was restarted, use the first time-stamp we've taken as the new-       * process startup time. */-      ts = sInitOnce.mFirstTimeStamp;-    } else {-      TimeStamp now = Now();-      uint64_t uptime = ComputeProcessUptime();--      ts = now - TimeDuration::FromMicroseconds(uptime);--      if ((ts > sInitOnce.mFirstTimeStamp) || (uptime == 0)) {-        /* If the process creation timestamp was inconsistent replace it with-         * the first one instead and notify that a telemetry error was-         * detected. */-        if (aIsInconsistent) {-          *aIsInconsistent = true;-        }-        ts = sInitOnce.mFirstTimeStamp;-      }-    }--    sInitOnce.mProcessCreation = ts;-  }-+MFBT_API TimeStamp TimeStamp::ProcessCreation() {   return sInitOnce.mProcessCreation; } void TimeStamp::RecordProcessRestart() {-  sInitOnce.mProcessCreation = TimeStamp();+  sInitOnce.mProcessCreation = TimeStamp::Now(); } }  // namespace mozilla

Analyzing the provided code diff for security fixes:

1. Vulnerability Existed: not sure  
   [Potential Time Manipulation Vulnerability] [mozglue/misc/TimeStamp.cpp] [Lines 36-69]  
   [Old Code]  
   ```cpp
   TimeStampInitialization() {
     TimeStamp::Startup();
     mFirstTimeStamp = TimeStamp::Now();
   ```
   [Fixed Code]  
   ```cpp
   TimeStampInitialization() {
     TimeStamp::Startup();
     TimeStamp now = TimeStamp::Now();
     // ... (additional logic for process creation time calculation)
     mFirstTimeStamp = now;
     mProcessCreation = process_creation;
   ```
   Additional Details: The change adds more robust time calculation logic, potentially addressing issues where process creation time could be manipulated or incorrectly calculated. However, without more context, it's unclear if this was specifically fixing a security vulnerability.

2. Vulnerability Existed: not sure  
   [Potential Information Leak or Inconsistent State] [mozglue/misc/TimeStamp.cpp] [Lines 47-69]  
   [Old Code]  
   ```cpp
   MFBT_API TimeStamp TimeStamp::ProcessCreation(bool* aIsInconsistent) {
     if (aIsInconsistent) {
       *aIsInconsistent = false;
     }
     // ... (complex logic with inconsistency checks)
   ```
   [Fixed Code]  
   ```cpp
   MFBT_API TimeStamp TimeStamp::ProcessCreation() {
     return sInitOnce.mProcessCreation;
   }
   ```
   Additional Details: The simplified version removes the inconsistency checking parameter and complex logic, potentially addressing issues where inconsistent state information could be leaked or mishandled. However, this might just be a code simplification rather than a security fix.

3. Vulnerability Existed: not sure  
   [Potential Time Reset Vulnerability] [mozglue/misc/TimeStamp.cpp] [Line 69]  
   [Old Code]  
   ```cpp
   void TimeStamp::RecordProcessRestart() {
     sInitOnce.mProcessCreation = TimeStamp();
   ```
   [Fixed Code]  
   ```cpp
   void TimeStamp::RecordProcessRestart() {
     sInitOnce.mProcessCreation = TimeStamp::Now();
   ```
   Additional Details: The change from setting a null timestamp to using the current time might prevent potential issues with uninitialized timestamps, but it's unclear if this was specifically addressing a security vulnerability.

Note: While these changes appear to improve the robustness of time handling, without additional context or vulnerability reports, it's difficult to definitively identify specific security vulnerabilities being fixed. The changes might be general improvements rather than security fixes.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/browser/components/about/AboutRedirector.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/components/about/AboutRedirector.cpp@@ -118,6 +118,10 @@      nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT |          nsIAboutModule::URI_CAN_LOAD_IN_CHILD | nsIAboutModule::ALLOW_SCRIPT |          nsIAboutModule::HIDE_FROM_ABOUTABOUT},+    {"pocket-style-guide", "chrome://pocket/content/panels/style-guide.html",+     nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT |+         nsIAboutModule::URI_CAN_LOAD_IN_CHILD | nsIAboutModule::ALLOW_SCRIPT |+         nsIAboutModule::HIDE_FROM_ABOUTABOUT},     {"preferences", "chrome://browser/content/preferences/preferences.xhtml",      nsIAboutModule::ALLOW_SCRIPT | nsIAboutModule::IS_SECURE_CHROME_UI},     {"downloads",

Based on the provided diff, I'll analyze it for potential security vulnerabilities:

Vulnerability Existed: not sure
[Potential Insecure Content Loading] [browser/components/about/AboutRedirector.cpp] [Lines 118-122]
[Old Code]
(No previous entry for "pocket-style-guide")
[Fixed Code]
{"pocket-style-guide", "chrome://pocket/content/panels/style-guide.html",
     nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT |
         nsIAboutModule::URI_CAN_LOAD_IN_CHILD | nsIAboutModule::ALLOW_SCRIPT |
         nsIAboutModule::HIDE_FROM_ABOUTABOUT},

Additional Details:
1. This appears to be a new addition rather than a fix to existing code
2. The flags include URI_SAFE_FOR_UNTRUSTED_CONTENT which suggests this content is meant to be safely exposed to untrusted contexts
3. The ALLOW_SCRIPT flag means JavaScript is enabled for this page
4. Without seeing the actual content of style-guide.html, we can't be certain about potential XSS vulnerabilities
5. The combination of allowing scripts and being safe for untrusted content could potentially be risky if the HTML content isn't properly sanitized

Note: Since this is an addition rather than a modification of existing code, it's harder to determine if it's fixing a vulnerability. The security implications would depend on the actual content being loaded from style-guide.html.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.