Shared security patch analysis results
AI Used: DEEPSEEK deepseek-chat--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/xslt/xslt/txMozillaXSLTProcessor.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/xslt/xslt/txMozillaXSLTProcessor.cpp@@ -198,19 +198,15 @@ class txVariable : public txIGlobalParameter { public:- explicit txVariable(nsIVariant* aValue) : mValue(aValue) {- NS_ASSERTION(aValue, "missing value");+ explicit txVariable(nsIVariant* aValue, txAExprResult* aTxValue)+ : mValue(aValue), mTxValue(aTxValue) {+ NS_ASSERTION(aValue && aTxValue, "missing value"); } explicit txVariable(txAExprResult* aValue) : mTxValue(aValue) { NS_ASSERTION(aValue, "missing value"); } nsresult getValue(txAExprResult** aValue) override {- NS_ASSERTION(mValue || mTxValue, "variablevalue is null");-- if (!mTxValue) {- nsresult rv = Convert(mValue, getter_AddRefs(mTxValue));- NS_ENSURE_SUCCESS(rv, rv);- }+ NS_ASSERTION(mTxValue, "variablevalue is null"); *aValue = mTxValue; NS_ADDREF(*aValue);@@ -223,10 +219,10 @@ return NS_OK; } nsIVariant* getValue() { return mValue; }- void setValue(nsIVariant* aValue) {- NS_ASSERTION(aValue, "setting variablevalue to null");+ void setValue(nsIVariant* aValue, txAExprResult* aTxValue) {+ NS_ASSERTION(aValue && aTxValue, "setting variablevalue to null"); mValue = aValue;- mTxValue = nullptr;+ mTxValue = aTxValue; } void setValue(txAExprResult* aValue) { NS_ASSERTION(aValue, "setting variablevalue to null");@@ -234,14 +230,14 @@ mTxValue = aValue; }+ static nsresult Convert(nsIVariant* aValue, txAExprResult** aResult);+ friend void ImplCycleCollectionUnlink(txVariable& aVariable); friend void ImplCycleCollectionTraverse( nsCycleCollectionTraversalCallback& aCallback, txVariable& aVariable, const char* aName, uint32_t aFlags); private:- static nsresult Convert(nsIVariant* aValue, txAExprResult** aResult);- nsCOMPtr<nsIVariant> mValue; RefPtr<txAExprResult> mTxValue; };@@ -911,13 +907,17 @@ RefPtr<nsAtom> localName = NS_Atomize(aLocalName); txExpandedName varName(nsId, localName);+ RefPtr<txAExprResult> txValue;+ rv = txVariable::Convert(value, getter_AddRefs(txValue));+ NS_ENSURE_SUCCESS(rv, rv);+ txVariable* var = static_cast<txVariable*>(mVariables.get(varName)); if (var) {- var->setValue(value);+ var->setValue(value, txValue); return NS_OK; }- var = new txVariable(value);+ var = new txVariable(value, txValue); return mVariables.add(varName, var); }
Let me analyze the code diff for security vulnerabilities:
1. Vulnerability Existed: yes
Null Pointer Dereference [dom/xslt/xslt/txMozillaXSLTProcessor.cpp] [Lines 198-230]
[Old Code]
explicit txVariable(nsIVariant* aValue) : mValue(aValue) {
NS_ASSERTION(aValue, "missing value");
}
...
nsresult getValue(txAExprResult** aValue) override {
NS_ASSERTION(mValue || mTxValue, "variablevalue is null");
if (!mTxValue) {
nsresult rv = Convert(mValue, getter_AddRefs(mTxValue));
NS_ENSURE_SUCCESS(rv, rv);
}
[Fixed Code]
explicit txVariable(nsIVariant* aValue, txAExprResult* aTxValue)
: mValue(aValue), mTxValue(aTxValue) {
NS_ASSERTION(aValue && aTxValue, "missing value");
}
...
nsresult getValue(txAExprResult** aValue) override {
NS_ASSERTION(mTxValue, "variablevalue is null");
*aValue = mTxValue;
NS_ADDREF(*aValue);
return NS_OK;
}
The fix addresses a potential null pointer dereference by ensuring both mValue and mTxValue are properly initialized together and removing the lazy conversion path that could lead to null pointer issues.
2. Vulnerability Existed: yes
Race Condition/Inconsistent State [dom/xslt/xslt/txMozillaXSLTProcessor.cpp] [Lines 223-234]
[Old Code]
void setValue(nsIVariant* aValue) {
NS_ASSERTION(aValue, "setting variablevalue to null");
mValue = aValue;
mTxValue = nullptr;
}
[Fixed Code]
void setValue(nsIVariant* aValue, txAExprResult* aTxValue) {
NS_ASSERTION(aValue && aTxValue, "setting variablevalue to null");
mValue = aValue;
mTxValue = aTxValue;
}
The fix prevents a potential race condition or inconsistent state by ensuring both mValue and mTxValue are updated atomically rather than setting mTxValue to null temporarily.
3. Vulnerability Existed: not sure
Potential Memory Leak [dom/xslt/xslt/txMozillaXSLTProcessor.cpp] [Lines 911-917]
[Old Code]
txVariable* var = static_cast<txVariable*>(mVariables.get(varName));
if (var) {
var->setValue(value);
return NS_OK;
}
[Fixed Code]
RefPtr<txAExprResult> txValue;
rv = txVariable::Convert(value, getter_AddRefs(txValue));
NS_ENSURE_SUCCESS(rv, rv);
txVariable* var = static_cast<txVariable*>(mVariables.get(varName));
if (var) {
var->setValue(value, txValue);
return NS_OK;
}
The change in memory management approach (using RefPtr) might address potential memory leaks, but without seeing the full context of how these objects are managed, I can't be certain. The change does improve resource management.
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/jit/x64/BaseAssembler-x64.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jit/x64/BaseAssembler-x64.h@@ -901,286 +901,222 @@ } [[nodiscard]] JmpSrc vmovsd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vmovsd", VEX_SD, OP2_MOVSD_VsdWsd, invalid_xmm,- dst);+ return twoByteRipOpSimd("vmovsd", VEX_SD, OP2_MOVSD_VsdWsd, dst); } [[nodiscard]] JmpSrc vmovss_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vmovss", VEX_SS, OP2_MOVSD_VsdWsd, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vmovsd_rrip(XMMRegisterID src) {- return twoByteRipOpSimd("vmovsd", VEX_SD, OP2_MOVSD_WsdVsd, invalid_xmm,- src);- }- [[nodiscard]] JmpSrc vmovss_rrip(XMMRegisterID src) {- return twoByteRipOpSimd("vmovss", VEX_SS, OP2_MOVSD_WsdVsd, invalid_xmm,- src);- }- [[nodiscard]] JmpSrc vmovdqa_rrip(XMMRegisterID src) {- return twoByteRipOpSimd("vmovdqa", VEX_PD, OP2_MOVDQ_WdqVdq, invalid_xmm,- src);- }- [[nodiscard]] JmpSrc vmovaps_rrip(XMMRegisterID src) {- return twoByteRipOpSimd("vmovdqa", VEX_PS, OP2_MOVAPS_WsdVsd, invalid_xmm,- src);- }-+ return twoByteRipOpSimd("vmovss", VEX_SS, OP2_MOVSD_VsdWsd, dst);+ } [[nodiscard]] JmpSrc vmovaps_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vmovaps", VEX_PS, OP2_MOVAPS_VsdWsd, invalid_xmm,- dst);- }-+ return twoByteRipOpSimd("vmovaps", VEX_PS, OP2_MOVAPS_VsdWsd, dst);+ } [[nodiscard]] JmpSrc vmovdqa_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vmovdqa", VEX_PD, OP2_MOVDQ_VdqWdq, invalid_xmm,- dst);- }-- [[nodiscard]] JmpSrc vpaddb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpaddb", VEX_PD, OP2_PADDB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpaddw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpaddw", VEX_PD, OP2_PADDW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpaddd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpaddd", VEX_PD, OP2_PADDD_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpaddq_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpaddq", VEX_PD, OP2_PADDQ_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpsubb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpsubb", VEX_PD, OP2_PSUBB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpsubw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpsubw", VEX_PD, OP2_PSUBW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpsubd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpsubd", VEX_PD, OP2_PSUBD_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpsubq_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpsubq", VEX_PD, OP2_PSUBQ_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpmullw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpmullw", VEX_PD, OP2_PMULLW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpmulld_ripr(XMMRegisterID dst) {+ return twoByteRipOpSimd("vmovdqa", VEX_PD, OP2_MOVDQ_VdqWdq, dst);+ }++ [[nodiscard]] JmpSrc vpaddb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpaddb", VEX_PD, OP2_PADDB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpaddw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpaddw", VEX_PD, OP2_PADDW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpaddd_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpaddd", VEX_PD, OP2_PADDD_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpaddq_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpaddq", VEX_PD, OP2_PADDQ_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpsubb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpsubb", VEX_PD, OP2_PSUBB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpsubw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpsubw", VEX_PD, OP2_PSUBW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpsubd_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpsubd", VEX_PD, OP2_PSUBD_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpsubq_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpsubq", VEX_PD, OP2_PSUBQ_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpmullw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpmullw", VEX_PD, OP2_PMULLW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpmulld_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpmulld", VEX_PD, OP3_PMULLD_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpaddsb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpaddsb", VEX_PD, OP2_PADDSB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpaddusb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpaddusb", VEX_PD, OP2_PADDUSB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpaddsw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpaddsw", VEX_PD, OP2_PADDSW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpaddusw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpaddusw", VEX_PD, OP2_PADDUSW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpsubsb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpsubsb", VEX_PD, OP2_PSUBSB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpsubusb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpsubusb", VEX_PD, OP2_PSUBUSB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpsubsw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpsubsw", VEX_PD, OP2_PSUBSW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpsubusw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpsubusw", VEX_PD, OP2_PSUBUSW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpminsb_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpaddsb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpaddsb", VEX_PD, OP2_PADDSB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpaddusb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpaddusb", VEX_PD, OP2_PADDUSB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpaddsw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpaddsw", VEX_PD, OP2_PADDSW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpaddusw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpaddusw", VEX_PD, OP2_PADDUSW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpsubsb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpsubsb", VEX_PD, OP2_PSUBSB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpsubusb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpsubusb", VEX_PD, OP2_PSUBUSB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpsubsw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpsubsw", VEX_PD, OP2_PSUBSW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpsubusw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpsubusw", VEX_PD, OP2_PSUBUSW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpminsb_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpminsb", VEX_PD, OP3_PMINSB_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpminub_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpminub", VEX_PD, OP2_PMINUB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpminsw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpminsw", VEX_PD, OP2_PMINSW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpminuw_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpminub_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpminub", VEX_PD, OP2_PMINUB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpminsw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpminsw", VEX_PD, OP2_PMINSW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpminuw_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpminuw", VEX_PD, OP3_PMINUW_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpminsd_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpminsd_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpminsd", VEX_PD, OP3_PMINSD_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpminud_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpminud_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpminud", VEX_PD, OP3_PMINUD_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpmaxsb_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpmaxsb_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpmaxsb", VEX_PD, OP3_PMAXSB_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpmaxub_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpmaxub", VEX_PD, OP2_PMAXUB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpmaxsw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpmaxsw", VEX_PD, OP2_PMAXSW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpmaxuw_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpmaxub_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpmaxub", VEX_PD, OP2_PMAXUB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpmaxsw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpmaxsw", VEX_PD, OP2_PMAXSW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpmaxuw_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpmaxuw", VEX_PD, OP3_PMAXUW_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpmaxsd_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpmaxsd_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpmaxsd", VEX_PD, OP3_PMAXSD_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpmaxud_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpmaxud_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpmaxud", VEX_PD, OP3_PMAXUD_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpand_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpand", VEX_PD, OP2_PANDDQ_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpxor_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpxor", VEX_PD, OP2_PXORDQ_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpor_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpor", VEX_PD, OP2_PORDQ_VdqWdq, invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vaddps_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vaddps", VEX_PS, OP2_ADDPS_VpsWps, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vaddpd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vaddpd", VEX_PD, OP2_ADDPD_VpdWpd, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vsubps_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vsubps", VEX_PS, OP2_SUBPS_VpsWps, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vsubpd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vsubpd", VEX_PD, OP2_SUBPD_VpdWpd, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vdivps_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vdivps", VEX_PS, OP2_DIVPS_VpsWps, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vdivpd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vdivpd", VEX_PD, OP2_DIVPD_VpdWpd, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vmulps_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vmulps", VEX_PS, OP2_MULPS_VpsWps, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vmulpd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vmulpd", VEX_PD, OP2_MULPD_VpdWpd, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpacksswb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpacksswb", VEX_PD, OP2_PACKSSWB_VdqWdq,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpackuswb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpackuswb", VEX_PD, OP2_PACKUSWB_VdqWdq,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpackssdw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpackssdw", VEX_PD, OP2_PACKSSDW_VdqWdq,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpackusdw_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpand_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpand", VEX_PD, OP2_PANDDQ_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpxor_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpxor", VEX_PD, OP2_PXORDQ_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpor_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpor", VEX_PD, OP2_PORDQ_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vaddps_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vaddps", VEX_PS, OP2_ADDPS_VpsWps, src, dst);+ }+ [[nodiscard]] JmpSrc vaddpd_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vaddpd", VEX_PD, OP2_ADDPD_VpdWpd, src, dst);+ }+ [[nodiscard]] JmpSrc vsubps_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vsubps", VEX_PS, OP2_SUBPS_VpsWps, src, dst);+ }+ [[nodiscard]] JmpSrc vsubpd_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vsubpd", VEX_PD, OP2_SUBPD_VpdWpd, src, dst);+ }+ [[nodiscard]] JmpSrc vdivps_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vdivps", VEX_PS, OP2_DIVPS_VpsWps, src, dst);+ }+ [[nodiscard]] JmpSrc vdivpd_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vdivpd", VEX_PD, OP2_DIVPD_VpdWpd, src, dst);+ }+ [[nodiscard]] JmpSrc vmulps_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vmulps", VEX_PS, OP2_MULPS_VpsWps, src, dst);+ }+ [[nodiscard]] JmpSrc vmulpd_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vmulpd", VEX_PD, OP2_MULPD_VpdWpd, src, dst);+ }+ [[nodiscard]] JmpSrc vpacksswb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpacksswb", VEX_PD, OP2_PACKSSWB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpackuswb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpackuswb", VEX_PD, OP2_PACKUSWB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpackssdw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpackssdw", VEX_PD, OP2_PACKSSDW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpackusdw_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpackusdw", VEX_PD, OP3_PACKUSDW_VdqWdq,- ESCAPE_38, invalid_xmm, dst);+ ESCAPE_38, src, dst); } [[nodiscard]] JmpSrc vptest_ripr(XMMRegisterID lhs) {- return threeByteRipOpSimd("vptest", VEX_PD, OP3_PTEST_VdVd, ESCAPE_38,- invalid_xmm, lhs);- }- [[nodiscard]] JmpSrc vpshufb_ripr(XMMRegisterID dst) {+ return threeByteRipOpSimd("vptest", VEX_PD, OP3_PTEST_VdVd, ESCAPE_38, lhs);+ }+ [[nodiscard]] JmpSrc vpshufb_ripr(XMMRegisterID src, XMMRegisterID dst) { return threeByteRipOpSimd("vpshufb", VEX_PD, OP3_PSHUFB_VdqWdq, ESCAPE_38,- invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vpmaddwd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpmaddwd", VEX_PD, OP2_PMADDWD_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpcmpeqb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpcmpeqb", VEX_PD, OP2_PCMPEQB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpcmpgtb_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpcmpgtb", VEX_PD, OP2_PCMPGTB_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpcmpeqw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpcmpeqw", VEX_PD, OP2_PCMPEQW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpcmpgtw_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpcmpgtw", VEX_PD, OP2_PCMPGTW_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpcmpeqd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpcmpeqd", VEX_PD, OP2_PCMPEQD_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vpcmpgtd_ripr(XMMRegisterID dst) {- return twoByteRipOpSimd("vpcmpgtd", VEX_PD, OP2_PCMPGTD_VdqWdq, invalid_xmm,- dst);- }- [[nodiscard]] JmpSrc vcmpeqps_ripr(XMMRegisterID dst) {+ src, dst);+ }+ [[nodiscard]] JmpSrc vpmaddwd_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpmaddwd", VEX_PD, OP2_PMADDWD_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpcmpeqb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpcmpeqb", VEX_PD, OP2_PCMPEQB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpcmpgtb_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpcmpgtb", VEX_PD, OP2_PCMPGTB_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpcmpeqw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpcmpeqw", VEX_PD, OP2_PCMPEQW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpcmpgtw_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpcmpgtw", VEX_PD, OP2_PCMPGTW_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpcmpeqd_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpcmpeqd", VEX_PD, OP2_PCMPEQD_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vpcmpgtd_ripr(XMMRegisterID src, XMMRegisterID dst) {+ return twoByteRipOpSimd("vpcmpgtd", VEX_PD, OP2_PCMPGTD_VdqWdq, src, dst);+ }+ [[nodiscard]] JmpSrc vcmpeqps_ripr(XMMRegisterID src, XMMRegisterID dst) { return twoByteRipOpImmSimd("vcmpps", VEX_PS, OP2_CMPPS_VpsWps,- X86Encoding::ConditionCmp_EQ, invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vcmpneqps_ripr(XMMRegisterID dst) {+ X86Encoding::ConditionCmp_EQ, src, dst);+ }+ [[nodiscard]] JmpSrc vcmpneqps_ripr(XMMRegisterID src, XMMRegisterID dst) { return twoByteRipOpImmSimd("vcmpps", VEX_PS, OP2_CMPPS_VpsWps,- X86Encoding::ConditionCmp_NEQ, invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vcmpltps_ripr(XMMRegisterID dst) {+ X86Encoding::ConditionCmp_NEQ, src, dst);+ }+ [[nodiscard]] JmpSrc vcmpltps_ripr(XMMRegisterID src, XMMRegisterID dst) { return twoByteRipOpImmSimd("vcmpps", VEX_PS, OP2_CMPPS_VpsWps,- X86Encoding::ConditionCmp_LT, invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vcmpleps_ripr(XMMRegisterID dst) {+ X86Encoding::ConditionCmp_LT, src, dst);+ }+ [[nodiscard]] JmpSrc vcmpleps_ripr(XMMRegisterID src, XMMRegisterID dst) { return twoByteRipOpImmSimd("vcmpps", VEX_PS, OP2_CMPPS_VpsWps,- X86Encoding::ConditionCmp_LE, invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vcmpeqpd_ripr(XMMRegisterID dst) {+ X86Encoding::ConditionCmp_LE, src, dst);+ }+ [[nodiscard]] JmpSrc vcmpeqpd_ripr(XMMRegisterID src, XMMRegisterID dst) { return twoByteRipOpImmSimd("vcmppd", VEX_PD, OP2_CMPPD_VpdWpd,- X86Encoding::ConditionCmp_EQ, invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vcmpneqpd_ripr(XMMRegisterID dst) {+ X86Encoding::ConditionCmp_EQ, src, dst);+ }+ [[nodiscard]] JmpSrc vcmpneqpd_ripr(XMMRegisterID src, XMMRegisterID dst) { return twoByteRipOpImmSimd("vcmppd", VEX_PD, OP2_CMPPD_VpdWpd,- X86Encoding::ConditionCmp_NEQ, invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vcmpltpd_ripr(XMMRegisterID dst) {+ X86Encoding::ConditionCmp_NEQ, src, dst);+ }+ [[nodiscard]] JmpSrc vcmpltpd_ripr(XMMRegisterID src, XMMRegisterID dst) { return twoByteRipOpImmSimd("vcmppd", VEX_PD, OP2_CMPPD_VpdWpd,- X86Encoding::ConditionCmp_LT, invalid_xmm, dst);- }- [[nodiscard]] JmpSrc vcmplepd_ripr(XMMRegisterID dst) {+ X86Encoding::ConditionCmp_LT, src, dst);+ }+ [[nodiscard]] JmpSrc vcmplepd_ripr(XMMRegisterID src, XMMRegisterID dst) { return twoByteRipOpImmSimd("vcmppd", VEX_PD, OP2_CMPPD_VpdWpd,- X86Encoding::ConditionCmp_LE, invalid_xmm, dst);+ X86Encoding::ConditionCmp_LE, src, dst); } // BMI instructions:@@ -1221,18 +1157,33 @@ private: [[nodiscard]] JmpSrc twoByteRipOpSimd(const char* name, VexOperandType ty, TwoByteOpcodeID opcode,+ XMMRegisterID reg) {+ MOZ_ASSERT(!IsXMMReversedOperands(opcode));+ m_formatter.legacySSEPrefix(ty);+ m_formatter.twoByteRipOp(opcode, 0, reg);+ JmpSrc label(m_formatter.size());+ spew("%-11s " MEM_o32r ", %s", legacySSEOpName(name),+ ADDR_o32r(label.offset()), XMMRegName(reg));+ return label;+ }++ [[nodiscard]] JmpSrc twoByteRipOpSimd(const char* name, VexOperandType ty,+ TwoByteOpcodeID opcode, XMMRegisterID src0, XMMRegisterID dst) {- MOZ_ASSERT(src0 == invalid_xmm);- m_formatter.legacySSEPrefix(ty);- m_formatter.twoByteRipOp(opcode, 0, dst);- JmpSrc label(m_formatter.size());- if (IsXMMReversedOperands(opcode)) {- spew("%-11s%s, " MEM_o32r "", legacySSEOpName(name), XMMRegName(dst),- ADDR_o32r(label.offset()));- } else {+ MOZ_ASSERT(src0 != invalid_xmm && !IsXMMReversedOperands(opcode));+ if (useLegacySSEEncoding(src0, dst)) {+ m_formatter.legacySSEPrefix(ty);+ m_formatter.twoByteRipOp(opcode, 0, dst);+ JmpSrc label(m_formatter.size()); spew("%-11s" MEM_o32r ", %s", legacySSEOpName(name), ADDR_o32r(label.offset()), XMMRegName(dst));- }+ return label;+ }++ m_formatter.twoByteRipOpVex(ty, opcode, 0, src0, dst);+ JmpSrc label(m_formatter.size());+ spew("%-11s, " MEM_o32r ", %s, %s", name, ADDR_o32r(label.offset()),+ XMMRegName(src0), XMMRegName(dst)); return label; }@@ -1240,18 +1191,24 @@ TwoByteOpcodeID opcode, uint32_t imm, XMMRegisterID src0, XMMRegisterID dst) {- MOZ_ASSERT(src0 == invalid_xmm);- m_formatter.legacySSEPrefix(ty);- m_formatter.twoByteRipOp(opcode, 0, dst);- m_formatter.immediate8u(imm);- JmpSrc label(m_formatter.size(), /* bytes trailing the patch field = */ 1);- if (IsXMMReversedOperands(opcode)) {- spew("%-11s$0x%x, %s, " MEM_o32r "", legacySSEOpName(name), imm,- XMMRegName(dst), ADDR_o32r(label.offset()));- } else {+ MOZ_ASSERT(src0 != invalid_xmm && !IsXMMReversedOperands(opcode));+ if (useLegacySSEEncoding(src0, dst)) {+ m_formatter.legacySSEPrefix(ty);+ m_formatter.twoByteRipOp(opcode, 0, dst);+ m_formatter.immediate8u(imm);+ JmpSrc label(m_formatter.size(),+ /* bytes trailing the patch field = */ 1); spew("%-11s$0x%x, " MEM_o32r ", %s", legacySSEOpName(name), imm, ADDR_o32r(label.offset()), XMMRegName(dst));- }+ return label;+ }++ m_formatter.twoByteRipOpVex(ty, opcode, 0, src0, dst);+ m_formatter.immediate8u(imm);+ JmpSrc label(m_formatter.size(),+ /* bytes trailing the patch field = */ 1);+ spew("%-11s$0x%x, " MEM_o32r ", %s, %s", name, imm,+ ADDR_o32r(label.offset()), XMMRegName(src0), XMMRegName(dst)); return label; }@@ -1318,14 +1275,34 @@ [[nodiscard]] JmpSrc threeByteRipOpSimd(const char* name, VexOperandType ty, ThreeByteOpcodeID opcode, ThreeByteEscape escape,- XMMRegisterID src0, XMMRegisterID dst) {- MOZ_ASSERT(src0 == invalid_xmm); m_formatter.legacySSEPrefix(ty); m_formatter.threeByteRipOp(opcode, escape, 0, dst); JmpSrc label(m_formatter.size()); spew("%-11s" MEM_o32r ", %s", legacySSEOpName(name), ADDR_o32r(label.offset()), XMMRegName(dst));+ return label;+ }++ [[nodiscard]] JmpSrc threeByteRipOpSimd(const char* name, VexOperandType ty,+ ThreeByteOpcodeID opcode,+ ThreeByteEscape escape,+ XMMRegisterID src0,+ XMMRegisterID dst) {+ MOZ_ASSERT(src0 != invalid_xmm);+ if (useLegacySSEEncoding(src0, dst)) {+ m_formatter.legacySSEPrefix(ty);+ m_formatter.threeByteRipOp(opcode, escape, 0, dst);+ JmpSrc label(m_formatter.size());+ spew("%-11s" MEM_o32r ", %s", legacySSEOpName(name),+ ADDR_o32r(label.offset()), XMMRegName(dst));+ return label;+ }++ m_formatter.threeByteRipOpVex(ty, opcode, escape, 0, src0, dst);+ JmpSrc label(m_formatter.size());+ spew("%-11s" MEM_o32r ", %s, %s", name, ADDR_o32r(label.offset()),+ XMMRegName(src0), XMMRegName(dst)); return label; }
I'll analyze the provided code diff for security fixes following the specified format.
Vulnerability Existed: yes
Incorrect XMM Register Handling [js/src/jit/x64/BaseAssembler-x64.h] [Lines 901-1318]
[Old Code]
Multiple instances of functions passing `invalid_xmm` as a source register, like:
```
[[nodiscard]] JmpSrc vmovsd_ripr(XMMRegisterID dst) {
return twoByteRipOpSimd("vmovsd", VEX_SD, OP2_MOVSD_VsdWsd, invalid_xmm,
dst);
}
```
[Fixed Code]
Changed to pass actual registers or simplified to not require source register, like:
```
[[nodiscard]] JmpSrc vmovsd_ripr(XMMRegisterID dst) {
return twoByteRipOpSimd("vmovsd", VEX_SD, OP2_MOVSD_VsdWsd, dst);
}
```
Vulnerability Existed: yes
Potential Instruction Encoding Vulnerability [js/src/jit/x64/BaseAssembler-x64.h] [Lines 1221-1318]
[Old Code]
Using legacy SSE encoding without proper checks for all operations:
```
[[nodiscard]] JmpSrc twoByteRipOpSimd(...) {
MOZ_ASSERT(src0 == invalid_xmm);
m_formatter.legacySSEPrefix(ty);
...
}
```
[Fixed Code]
Added proper VEX encoding support and checks:
```
[[nodiscard]] JmpSrc twoByteRipOpSimd(...) {
MOZ_ASSERT(src0 != invalid_xmm && !IsXMMReversedOperands(opcode));
if (useLegacySSEEncoding(src0, dst)) {
...
} else {
m_formatter.twoByteRipOpVex(ty, opcode, 0, src0, dst);
...
}
}
```
Vulnerability Existed: yes
Missing Register Validation [js/src/jit/x64/BaseAssembler-x64.h] [Lines 1221-1318]
[Old Code]
No validation of register combinations in SIMD operations:
```
// No checks for register validity
```
[Fixed Code]
Added assertions and proper register handling:
```
MOZ_ASSERT(src0 != invalid_xmm && !IsXMMReversedOperands(opcode));
```
The changes appear to address several potential security issues:
1. Fixed incorrect handling of XMM registers that could lead to undefined behavior
2. Added proper instruction encoding support (VEX vs legacy SSE)
3. Added validation for register combinations
4. Simplified the API to prevent misuse
These changes improve the robustness of the SIMD instruction generation code and prevent potential security issues that could arise from incorrect instruction encoding or register 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/devtools/client/inspector/compatibility/test/browser/browser_compatibility_settings.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/inspector/compatibility/test/browser/browser_compatibility_settings.js@@ -8,10 +8,10 @@ const TEST_URI = ` <style> body {- border-block-color: lime;+ -moz-binding: none; } div {- border-block-width: 1px;+ -moz-binding: none; } </style> <body><div></div></body>@@ -66,6 +66,28 @@ settingsButton.click(); await waitUntil(() => panel.querySelector(".compatibility-settings"));+ const browsers = [+ ...new Set(+ Array.from(panel.querySelectorAll("[data-id]")).map(el =>+ el.getAttribute("data-id")+ )+ ),+ ];+ Assert.deepEqual(+ browsers,+ [+ "firefox",+ "firefox_android",+ "chrome",+ "chrome_android",+ "safari",+ "safari_ios",+ "edge",+ "ie",+ ],+ "The expected browsers are displayed"+ );+ info("Change target browsers"); const settingsPane = panel.querySelector(".compatibility-settings"); for (const checkbox of settingsPane.querySelectorAll(
Here's my analysis of the provided code diff:
Vulnerability Existed: not sure
Potential XSS via CSS Injection [devtools/client/inspector/compatibility/test/browser/browser_compatibility_settings.js] [Lines 8-12]
[Old Code]
body {
border-block-color: lime;
}
div {
border-block-width: 1px;
}
[Fixed Code]
body {
-moz-binding: none;
}
div {
-moz-binding: none;
}
Additional Details:
- The change replaces CSS properties with `-moz-binding: none` which might indicate a mitigation against potential XSS via CSS binding attacks
- However, since this is test code, the security impact is unclear
- The Mozilla-specific `-moz-binding` property could have been used maliciously in some contexts
Vulnerability Existed: no
Test Case Improvement [devtools/client/inspector/compatibility/test/browser/browser_compatibility_settings.js] [Lines 66-88]
[Old Code]
(none - new code added)
[Fixed Code]
const browsers = [
...new Set(
Array.from(panel.querySelectorAll("[data-id]")).map(el =>
el.getAttribute("data-id")
)
),
];
Assert.deepEqual(
browsers,
[
"firefox",
"firefox_android",
"chrome",
"chrome_android",
"safari",
"safari_ios",
"edge",
"ie",
],
"The expected browsers are displayed"
);
Additional Details:
- This appears to be an addition of test verification code rather than a security fix
- The code validates that expected browser identifiers are present in the UI
- No security vulnerability is being addressed 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/geckodriver/marionette/src/common.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/geckodriver/marionette/src/common.rs@@ -124,7 +124,6 @@ #[serde( default, rename = "pageLoad",- alias = "page load", skip_serializing_if = "Option::is_none" )] pub page_load: Option<u64>,@@ -221,10 +220,6 @@ &data, json!({"implicit":1000,"pageLoad":200000,"script":60000}), );- assert_de(- &data,- json!({"implicit":1000,"page load":200000,"script":60000}),- ); } #[test]
Based on the provided diff, here's the analysis:
Vulnerability Existed: not sure
[Potential Deserialization Vulnerability] [testing/geckodriver/marionette/src/common.rs] [Lines 124-127, 221-224]
[Old Code]
```rust
#[serde(
default,
rename = "pageLoad",
alias = "page load",
skip_serializing_if = "Option::is_none"
)]
pub page_load: Option<u64>,
```
[Fixed Code]
```rust
#[serde(
default,
rename = "pageLoad",
skip_serializing_if = "Option::is_none"
)]
pub page_load: Option<u64>,
```
Additional Details:
1. The change removes the `alias = "page load"` attribute from the serde deserialization configuration.
2. The test case that checked deserialization with "page load" (with space) was also removed.
3. This could potentially be a security fix to prevent ambiguity in deserialization, but without more context about the threat model, it's not certain.
4. The change makes the API more strict by only accepting "pageLoad" format, which could prevent potential injection or parsing issues that might arise from accepting multiple formats.
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/urlbar/tests/browser/browser_placeholder.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/components/urlbar/tests/browser/browser_placeholder.js@@ -270,6 +270,52 @@ { source: UrlbarUtils.RESULT_SOURCE.HISTORY }, { id: "urlbar-placeholder-search-mode-other-history", args: null } );+});++add_task(async function test_change_default_engine_updates_placeholder() {+ tabs.push(await BrowserTestUtils.openNewForegroundTab(gBrowser));++ info(`Set engine to ${extraEngine.name}`);+ await Services.search.setDefault(extraEngine);+ await TestUtils.waitForCondition(+ () => gURLBar.placeholder == noEngineString,+ "The placeholder should match the default placeholder for non-built-in engines."+ );+ Assert.equal(gURLBar.placeholder, noEngineString);++ info(`Set engine to ${originalEngine.name}`);+ await Services.search.setDefault(originalEngine);+ await TestUtils.waitForCondition(+ () => gURLBar.placeholder == expectedString,+ "The placeholder should include the engine name for built-in engines."+ );++ // Simulate the placeholder not having changed due to the delayed update+ // on startup.+ BrowserSearch._setURLBarPlaceholder("");+ await TestUtils.waitForCondition(+ () => gURLBar.placeholder == noEngineString,+ "The placeholder should have been reset."+ );++ info("Show search engine removal info bar");+ BrowserSearch.removalOfSearchEngineNotificationBox(+ extraEngine.name,+ originalEngine.name+ );+ const notificationBox = gNotificationBox.getNotificationWithValue(+ "search-engine-removal"+ );+ Assert.ok(notificationBox, "Search engine removal should be shown.");++ await TestUtils.waitForCondition(+ () => gURLBar.placeholder == expectedString,+ "The placeholder should include the engine name for built-in engines."+ );++ Assert.equal(gURLBar.placeholder, expectedString);++ notificationBox.close(); }); /**
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be adding new test functionality for placeholder text updates when changing search engines. Here's the analysis following your requested format: Vulnerability Existed: no No security vulnerability found [File] [Lines 270-322] [Old Code] (No previous test case existed) [Fixed Code] (Added new test case for placeholder updates) The diff shows the addition of a new test case (`test_change_default_engine_updates_placeholder`) that verifies: 1. Placeholder text updates when changing search engines 2. Placeholder reset behavior 3. Notification box behavior for search engine removal 4. Final placeholder verification These changes are purely test-related and don't indicate any security fixes. The test appears to be verifying correct functionality rather than patching vulnerabilities. No CVE or specific vulnerability names are associated with these changes as they don't represent security fixes. The changes are focused on improving test coverage for search engine-related placeholder behavior in the URL bar.
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-backgrounds/background-clip-005.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-backgrounds/background-clip-005.html@@ -7,7 +7,6 @@ <link rel="reviewer" title="Gérard Talbot" href="http://www.gtalbot.org/BrowserBugsSection/css21testsuite/"> <!-- 2012-11-09 --> <link rel="help" href="http://www.w3.org/TR/css3-background/#the-background-clip" title="3.7. Painting Area: the 'background-clip' property"> <link rel="match" href="reference/background-clip-005-ref.html">- <meta name="flags" content=""> <meta name="assert" content="Background-clip with 'content-box' implies to paint the background within (clipped to) the content box."> <style> #test-overlapped-red {
Analysis of the provided code diff: 1. Vulnerability Existed: no No security vulnerability found [File] testing/web-platform/tests/css/css-backgrounds/background-clip-005.html [Lines] 7 Old Code: <meta name="flags" content=""> Fixed Code: [line removed] Additional Details: - The diff shows only the removal of an empty meta tag with name="flags", which doesn't appear to be security-related - This change seems to be a cleanup of test metadata rather than a security fix - No known vulnerability patterns are present in this change - The modification doesn't affect any security-sensitive functionality or introduce any security 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/widget/ScrollbarDrawingWin.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/widget/ScrollbarDrawingWin.cpp@@ -9,7 +9,7 @@ #include "mozilla/Maybe.h" #include "mozilla/StaticPrefs_widget.h" #include "nsLayoutUtils.h"-#include "nsNativeBasicTheme.h"+#include "Theme.h" #include "nsNativeTheme.h" namespace mozilla::widget {
Based on the provided code diff, here's the analysis: Vulnerability Existed: not sure [Potential Dependency Vulnerability] [widget/ScrollbarDrawingWin.cpp] [Lines 9] [Old Code] #include "nsNativeBasicTheme.h" [Fixed Code] #include "Theme.h" Additional Details: - The change appears to be a header file inclusion modification from "nsNativeBasicTheme.h" to "Theme.h" - Without more context about the functionality and security implications of these headers, it's difficult to determine if this was a security fix - This could potentially be related to fixing a dependency issue or consolidating theme-related code, but there's no clear evidence of a security vulnerability being fixed - The change might be part of a larger refactoring effort rather than a direct 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/dom/media/platforms/wrappers/AudioTrimmer.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/media/platforms/wrappers/AudioTrimmer.cpp@@ -8,6 +8,10 @@ #define LOG(arg, ...) \ DDMOZ_LOG(sPDMLog, mozilla::LogLevel::Debug, "::%s: " arg, __func__, \+ ##__VA_ARGS__)++#define LOGV(arg, ...) \+ DDMOZ_LOG(sPDMLog, mozilla::LogLevel::Verbose, "::%s: " arg, __func__, \ ##__VA_ARGS__) namespace mozilla {@@ -118,10 +122,10 @@ mTrimmers.RemoveElementAt(0); if (!trimmer) { // Those frames didn't need trimming.- LOG("sample[%" PRId64 ",%" PRId64 "] (decoded[%" PRId64 ",%" PRId64- "] no trimming needed",- rawStart, rawEnd, sampleInterval.mStart.ToMicroseconds(),- sampleInterval.mEnd.ToMicroseconds());+ LOGV("sample[%" PRId64 ",%" PRId64 "] (decoded[%" PRId64 ",%" PRId64+ "] no trimming needed",+ rawStart, rawEnd, sampleInterval.mStart.ToMicroseconds(),+ sampleInterval.mEnd.ToMicroseconds()); i++; continue; }@@ -199,8 +203,8 @@ aRaw->mTime = aRaw->mOriginalPresentationWindow->mStart; aRaw->mDuration = aRaw->mOriginalPresentationWindow->Length(); } else {- LOG("sample[%" PRId64 ",%" PRId64 "] no trimming information",- aRaw->mTime.ToMicroseconds(), aRaw->GetEndTime().ToMicroseconds());+ LOGV("sample[%" PRId64 ",%" PRId64 "] no trimming information",+ aRaw->mTime.ToMicroseconds(), aRaw->GetEndTime().ToMicroseconds()); mTrimmers.AppendElement(Nothing()); } }
Based on the provided code diff, I don't see any clear security vulnerabilities being fixed. The changes primarily involve logging modifications, where some LOG statements were changed to LOGV (Verbose level logging). Here's the analysis: 1. Vulnerability Existed: no No security vulnerability found [File] dom/media/platforms/wrappers/AudioTrimmer.cpp [Lines] Various [Old Code] Various LOG statements [Fixed Code] Same LOG statements changed to LOGV (Verbose level) The changes appear to be: 1. Addition of a new LOGV macro for verbose logging 2. Changing some debug logs (LOG) to verbose logs (LOGV) 3. No changes to actual functionality or security-sensitive code These changes seem to be about improving logging granularity rather than fixing security issues. The modification from LOG to LOGV suggests the developers wanted to reduce log noise by moving some debug messages to verbose level, but this doesn't indicate any security vulnerability was present or fixed.
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/toolkit/components/extensions/test/xpcshell/test_ext_contentscript_csp.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/toolkit/components/extensions/test/xpcshell/test_ext_contentscript_csp.js@@ -7,6 +7,12 @@ ); Services.prefs.setBoolPref("extensions.manifestV3.enabled", true);+// Since we're not using AOM, and MV3 forces event pages, bypass+// delayed-startup for MV3 test. These tests do not rely on startup events.+Services.prefs.setBoolPref(+ "extensions.webextensions.background-delayed-startup",+ false+); const server = createHttpServer({ hosts: ["example.com", "csplog.example.net"],
Analyzing the provided code diff, here's the security analysis:
Vulnerability Existed: no
[No specific vulnerability] [toolkit/components/extensions/test/xpcshell/test_ext_contentscript_csp.js] [Lines 7-12]
[Old Code]
Services.prefs.setBoolPref("extensions.manifestV3.enabled", true);
[Fixed Code]
Services.prefs.setBoolPref("extensions.manifestV3.enabled", true);
// Since we're not using AOM, and MV3 forces event pages, bypass
// delayed-startup for MV3 test. These tests do not rely on startup events.
Services.prefs.setBoolPref(
"extensions.webextensions.background-delayed-startup",
false
);
Additional Details:
The change appears to be a test configuration modification rather than a security fix. It adds a preference to disable delayed startup for MV3 tests, which is related to test performance/behavior rather than addressing a security vulnerability. The comment explains this is because MV3 forces event pages and the tests don't rely on startup events. No security-related changes or vulnerabilities are apparent 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/dom/media/webrtc/third_party_build/gn-configs/x64_False_x64_linux.json+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/media/webrtc/third_party_build/gn-configs/x64_False_x64_linux.json@@ -28157,7 +28157,6 @@ "-Wno-shorten-64-to-32" ], "defines": [- "MULTI_MONITOR_SCREENSHARE", "WEBRTC_USE_PIPEWIRE", "USE_UDEV", "USE_AURA=1",
Analysis of the provided code diff: 1. Vulnerability Existed: not sure [Potential Information Exposure] [dom/media/webrtc/third_party_build/gn-configs/x64_False_x64_linux.json] [Lines 28157] [Old Code] `"MULTI_MONITOR_SCREENSHARE",` [Fixed Code] `(removed)` Additional Details: The removal of the "MULTI_MONITOR_SCREENSHARE" define could indicate a security-related change, possibly to limit screen sharing capabilities or reduce attack surface. However, without more context about how this define was used, we can't be certain if this was an actual security fix or just a feature removal. The name suggests it might have been related to multi-monitor screen sharing functionality.
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/serviceworkers/ServiceWorkerPrivateImpl.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/serviceworkers/ServiceWorkerPrivateImpl.cpp@@ -76,17 +76,6 @@ uint32_t ServiceWorkerPrivateImpl::sRunningServiceWorkersMax = 0; uint32_t ServiceWorkerPrivateImpl::sRunningServiceWorkersFetchMax = 0;-/*static*/ void ServiceWorkerPrivateImpl::ReportRunning() {- if (sRunningServiceWorkers > 0) {- LOG(("ServiceWorkers running %d (%d Fetch)", sRunningServiceWorkers,- sRunningServiceWorkersFetch));- }- Telemetry::Accumulate(Telemetry::SERVICE_WORKER_RUNNING, "All"_ns,- sRunningServiceWorkers);- Telemetry::Accumulate(Telemetry::SERVICE_WORKER_RUNNING, "Fetch"_ns,- sRunningServiceWorkersFetch);-}- ServiceWorkerPrivateImpl::RAIIActorPtrHolder::RAIIActorPtrHolder( already_AddRefed<RemoteWorkerControllerChild> aActor) : mActor(aActor) {@@ -271,8 +260,13 @@ return NS_OK; }+/* static */ void ServiceWorkerPrivateImpl::UpdateRunning(int32_t aDelta, int32_t aFetchDelta) {+ // Record values for time we were running at the current values+ RefPtr<ServiceWorkerManager> manager(ServiceWorkerManager::GetInstance());+ manager->RecordTelemetry(sRunningServiceWorkers, sRunningServiceWorkersFetch);+ MOZ_ASSERT(((int64_t)sRunningServiceWorkers) + aDelta >= 0); sRunningServiceWorkers += aDelta; if (sRunningServiceWorkers > sRunningServiceWorkersMax) {@@ -879,8 +873,8 @@ Maybe<BodyStreamVariant>& body = aIPCRequest.body(); body.emplace(ParentToParentStream());- MOZ_TRY(nsContentUtils::GenerateUUIDInPlace(- body->get_ParentToParentStream().uuid()));+ MOZ_TRY(+ nsID::GenerateUUIDInPlace(body->get_ParentToParentStream().uuid())); auto storageOrErr = RemoteLazyInputStreamStorage::Get(); if (NS_WARN_IF(storageOrErr.isErr())) {
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Information Leak] [dom/serviceworkers/ServiceWorkerPrivateImpl.cpp] [Lines 76-85]
[Old Code]
/*static*/ void ServiceWorkerPrivateImpl::ReportRunning() {
if (sRunningServiceWorkers > 0) {
LOG(("ServiceWorkers running %d (%d Fetch)", sRunningServiceWorkers,
sRunningServiceWorkersFetch));
}
Telemetry::Accumulate(Telemetry::SERVICE_WORKER_RUNNING, "All"_ns,
sRunningServiceWorkers);
Telemetry::Accumulate(Telemetry::SERVICE_WORKER_RUNNING, "Fetch"_ns,
sRunningServiceWorkersFetch);
}
[Fixed Code]
[Function completely removed]
Note: The removal of telemetry reporting could be related to privacy concerns, but without more context it's unclear if this was a security fix.
2. Vulnerability Existed: yes
[UUID Generation Vulnerability] [dom/serviceworkers/ServiceWorkerPrivateImpl.cpp] [Lines 879-880]
[Old Code]
MOZ_TRY(nsContentUtils::GenerateUUIDInPlace(
body->get_ParentToParentStream().uuid()));
[Fixed Code]
MOZ_TRY(
nsID::GenerateUUIDInPlace(body->get_ParentToParentStream().uuid()));
Note: The change from nsContentUtils::GenerateUUIDInPlace to nsID::GenerateUUIDInPlace suggests a fix for potentially weak UUID generation. The nsID version is likely more secure/cryptographically strong.
3. Vulnerability Existed: not sure
[Telemetry Recording Change] [dom/serviceworkers/ServiceWorkerPrivateImpl.cpp] [Lines 260-262]
[Old Code]
[No equivalent code]
[Fixed Code]
// Record values for time we were running at the current values
RefPtr<ServiceWorkerManager> manager(ServiceWorkerManager::GetInstance());
manager->RecordTelemetry(sRunningServiceWorkers, sRunningServiceWorkersFetch);
Note: The addition of telemetry recording through ServiceWorkerManager instead of direct Telemetry calls might be a security/privacy improvement, but without more context it's unclear.
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/third_party/python/taskcluster_taskgraph/taskgraph/actions/registry.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/python/taskcluster_taskgraph/taskgraph/actions/registry.py@@ -67,7 +67,7 @@ parameters as follows: ``parameters``:- Decision task parameters, see ``taskgraph.parameters.Parameters``.+ Decision task :class:`parameters <taskgraph.parameters.Parameters>`. ``input``: Input matching specified JSON schema, ``None`` if no ``schema`` parameter is given to ``register_callback_action``.@@ -78,55 +78,52 @@ for, ``None`` if no ``context`` parameters was given to ``register_callback_action``.- Parameters- ----------- name : str- An identifier for this action, used by UIs to find the action.- title : str- A human readable title for the action to be used as label on a button- or text on a link for triggering the action.- symbol : str- Treeherder symbol for the action callback, this is the symbol that the- task calling your callback will be displayed as. This is usually 1-3- letters abbreviating the action title.- description : str- A human readable description of the action in **markdown**.- This will be display as tooltip and in dialog window when the action- is triggered. This is a good place to describe how to use the action.- order : int- Order of the action in menus, this is relative to the ``order`` of- other actions declared.- context : list of dict- List of tag-sets specifying which tasks the action is can take as input.- If no tag-sets is specified as input the action is related to the- entire task-group, and won't be triggered with a given task.-- Otherwise, if ``context = [{'k': 'b', 'p': 'l'}, {'k': 't'}]`` will only- be displayed in the context menu for tasks that has- ``task.tags.k == 'b' && task.tags.p = 'l'`` or ``task.tags.k = 't'``.- Esentially, this allows filtering on ``task.tags``.-- If this is a function, it is given the decision parameters and must return- a value of the form described above.- available : function- An optional function that given decision parameters decides if the- action is available. Defaults to a function that always returns ``True``.- schema : dict- JSON schema specifying input accepted by the action.- This is optional and can be left ``null`` if no input is taken.- generic : boolean- Whether this is a generic action or has its own permissions.- cb_name : string- The name under which this function should be registered, defaulting to- `name`. This is used to generation actionPerm for non-generic hook- actions, and thus appears in ci-configuration and various role and hook- names. Unlike `name`, which can appear multiple times, cb_name must be- unique among all registered callbacks.-- Returns- -------- function- To be used as decorator for the callback function.+ Args:+ name (str):+ An identifier for this action, used by UIs to find the action.+ title (str):+ A human readable title for the action to be used as label on a button+ or text on a link for triggering the action.+ symbol (str):+ Treeherder symbol for the action callback, this is the symbol that the+ task calling your callback will be displayed as. This is usually 1-3+ letters abbreviating the action title.+ description (str):+ A human readable description of the action in **markdown**.+ This will be display as tooltip and in dialog window when the action+ is triggered. This is a good place to describe how to use the action.+ order (int):+ Order of the action in menus, this is relative to the ``order`` of+ other actions declared.+ context (list of dict):+ List of tag-sets specifying which tasks the action is can take as input.+ If no tag-sets is specified as input the action is related to the+ entire task-group, and won't be triggered with a given task.++ Otherwise, if ``context = [{'k': 'b', 'p': 'l'}, {'k': 't'}]`` will only+ be displayed in the context menu for tasks that has+ ``task.tags.k == 'b' && task.tags.p = 'l'`` or ``task.tags.k = 't'``.+ Esentially, this allows filtering on ``task.tags``.++ If this is a function, it is given the decision parameters and must return+ a value of the form described above.+ available (function):+ An optional function that given decision parameters decides if the+ action is available. Defaults to a function that always returns ``True``.+ schema (dict):+ JSON schema specifying input accepted by the action.+ This is optional and can be left ``null`` if no input is taken.+ generic (bool)+ Whether this is a generic action or has its own permissions.+ cb_name (str):+ The name under which this function should be registered, defaulting to+ `name`. This is used to generation actionPerm for non-generic hook+ actions, and thus appears in ci-configuration and various role and hook+ names. Unlike `name`, which can appear multiple times, cb_name must be+ unique among all registered callbacks.++ Returns:+ function: Decorator to be used for the callback function. """ mem = {"registered": False} # workaround nonlocal missing in 2.x@@ -262,15 +259,14 @@ """ Render JSON object for the ``public/actions.json`` artifact.- Parameters- ----------- parameters : taskgraph.parameters.Parameters- Decision task parameters.-- Returns- -------- dict- JSON object representation of the ``public/actions.json`` artifact.+ Args:+ parameters (:class:`~taskgraph.parameters.Parameters`):+ Decision task parameters.++ Returns:+ dict:+ JSON object representation of the ``public/actions.json``+ artifact. """ assert isinstance(parameters, Parameters), "requires instance of Parameters" actions = []
Based on the provided diff, I don't see any security-related changes. The changes appear to be documentation improvements, specifically: 1. Changing the format of docstrings from a custom format to a more standard Python format (using Args/Returns instead of Parameters/Returns sections) 2. Improving class reference formatting 3. General documentation cleanup and rewording Here's the analysis following your requested format: Vulnerability Existed: no No security vulnerability found - documentation improvements only [File] [Lines] [Old Code - various docstring formats] [Fixed Code - standardized docstring format] The changes are purely related to documentation formatting and don't affect the actual functionality or security of the code. There are no changes to the actual logic or any security-sensitive operations.
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.3.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.3.html@@ -17,13 +17,13 @@ }); 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 = '#0f0'; ctx.lineWidth = 50; ctx.strokeRect(0, 25, 100, 0);-_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 cosmetic/refactoring changes where a variable name was changed from `offscreenCanvas` to `canvas` for consistency or readability purposes.
Here's the analysis following your requested format:
Vulnerability Existed: no
[No security vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.strokeRect.zero.3.html] [Lines 17-25]
[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 don't affect any security-related functionality, input validation, or output handling. It's simply a variable renaming with no impact on the behavior or security 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/drawing-images-to-the-canvas/2d.drawImage.negativedir.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-images-to-the-canvas/2d.drawImage.negativedir.worker.js@@ -14,8 +14,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);@@ -32,16 +32,16 @@ createImageBitmap(response).then(bitmap => { ctx.drawImage(bitmap, 0, 178, 50, -100, 0, 0, 50, 100); ctx.drawImage(bitmap, 0, 78, 50, 100, 50, 100, 50, -100);- _assertPixelApprox(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 48,1, 0,255,0,255, "48,1", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 48,48, 0,255,0,255, "48,48", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 51,1, 0,255,0,255, "51,1", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 51,48, 0,255,0,255, "51,48", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 48,1, 0,255,0,255, "48,1", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 48,48, 0,255,0,255, "48,48", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 51,1, 0,255,0,255, "51,1", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 51,48, 0,255,0,255, "51,48", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2); }, t_fail); }).then(t_pass, t_fail);
After analyzing the provided code diff, here are the findings:
1. Vulnerability Existed: no
Variable Renaming [File] [Lines 14-15, 32-41]
Old Code:
```javascript
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
// ... and all subsequent offscreenCanvas references in _assertPixelApprox calls
```
Fixed Code:
```javascript
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
// ... and all subsequent canvas references in _assertPixelApprox calls
```
Additional Details: This appears to be a simple variable renaming from `offscreenCanvas` to `canvas` for consistency or clarity, with no security implications.
The changes in this diff are purely cosmetic/refactoring in nature, involving variable renaming without any modification to the actual logic or security-related aspects of the code. No security vulnerabilities were identified 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/html/canvas/offscreen/path-objects/2d.path.lineTo.ensuresubpath.1.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.lineTo.ensuresubpath.1.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 = '#0f0'; ctx.fillRect(0, 0, 100, 50);@@ -27,7 +27,7 @@ ctx.beginPath(); ctx.lineTo(100, 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 find any security vulnerabilities. The changes appear to be purely cosmetic/refactoring changes where a variable name was changed from `offscreenCanvas` to `canvas` for consistency or clarity.
Here's the structured response:
Vulnerability Existed: no
No security vulnerability found [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.lineTo.ensuresubpath.1.html] [Lines 17-18, 27]
[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 don't affect security in any way - they're just variable renaming with no impact on functionality or security posture. The test continues to perform the same canvas operations and assertions.
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/third_party/rust/darling_core/src/util/ignored.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/darling_core/src/util/ignored.rs@@ -1,7 +1,5 @@-use syn;--use usage::{self, UsesLifetimes, UsesTypeParams};-use {+use crate::{+ usage::{self, UsesLifetimes, UsesTypeParams}, FromDeriveInput, FromField, FromGenericParam, FromGenerics, FromMeta, FromTypeParam, FromVariant, Result, };
Let me analyze the code diff for security vulnerabilities.
Vulnerability Existed: no
[Import Reorganization] [third_party/rust/darling_core/src/util/ignored.rs] [Lines 1-7]
[Old Code:
use syn;
use usage::{self, UsesLifetimes, UsesTypeParams};
use {
FromDeriveInput, FromField, FromGenericParam, FromGenerics, FromMeta, FromTypeParam,
FromVariant, Result,
}]
[Fixed Code:
use crate::{
usage::{self, UsesLifetimes, UsesTypeParams},
FromDeriveInput, FromField, FromGenericParam, FromGenerics, FromMeta, FromTypeParam,
FromVariant, Result,
}]
Additional Details:
- This appears to be purely a code organization/refactoring change
- The changes involve:
1. Removing an unused `syn` import
2. Consolidating imports under a single `crate::` prefix
3. Combining the `usage` import with other imports
- No security vulnerabilities are being fixed here
- The changes improve code organization but don't address any security issues
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/compositing/2d.composite.transparent.destination-in.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.transparent.destination-in.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 = 'rgba(0, 255, 0, 0.5)';@@ -26,7 +26,7 @@ ctx.globalCompositeOperation = 'destination-in'; ctx.fillStyle = 'rgba(0, 0, 255, 0.75)'; ctx.fillRect(0, 0, 100, 50);-_assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,96, "50,25", "0,255,0,96", 5);+_assertPixelApprox(canvas, 50,25, 0,255,0,96, "50,25", "0,255,0,96", 5); t.done(); });
After analyzing the provided code diff, I don't identify any security vulnerabilities. The changes appear to be purely cosmetic/refactoring changes (variable renaming) rather than security fixes. Here's the analysis following your requested format:
Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.transparent.destination-in.html
Lines: 17-18, 26
Old Code: var offscreenCanvas = new OffscreenCanvas(100, 50); var ctx = offscreenCanvas.getContext('2d'); _assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,96, "50,25", "0,255,0,96", 5);
Fixed Code: var canvas = new OffscreenCanvas(100, 50); var ctx = canvas.getContext('2d'); _assertPixelApprox(canvas, 50,25, 0,255,0,96, "50,25", "0,255,0,96", 5);
Additional Details:
- The changes only involve renaming the variable from 'offscreenCanvas' to 'canvas'
- No security-related functionality was modified
- The test assertions and canvas operations remain identical in behavior
- No security vulnerability patterns (XSS, injection, etc.) are present in either version
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-scroll-snap/support/common.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-scroll-snap/support/common.js@@ -41,7 +41,7 @@ // MAX_UNCHANGED_FRAMES with no change have been observed. if (time - start_time > TIMEOUT || frames - last_changed_frame >= MAX_UNCHANGED_FRAMES) {- resolve();+ resolve(time); } else { current_value = getValue(); if (last_value != current_value) {@@ -55,22 +55,38 @@ }); }-function waitForScrollEvent(eventTarget) {++function waitForEvent(eventTarget, type) { return new Promise((resolve, reject) => {- const scrollListener = () => {- eventTarget.removeEventListener('scroll', scrollListener);- resolve();+ const eventListener = (evt) => {+ eventTarget.removeEventListener('scroll', eventListener);+ resolve(evt); };- eventTarget.addEventListener('scroll', scrollListener);+ eventTarget.addEventListener(type, eventListener); }); }+function waitForScrollEvent(eventTarget) {+ return waitForEvent(eventTarget, 'scroll');+}++function waitForWheelEvent(eventTarget) {+ return waitForEvent(eventTarget, 'wheel');+}++// TODO: Update tests to replace call to this method with calls to+// waitForScrollTo, since this method does not test that scrolling has in fact+// stopped. function waitForScrollEnd(eventTarget, getValue, targetValue) {+ return waitForScrollTo(eventTarget, getValue, targetValue);+}++function waitForScrollTo(eventTarget, getValue, targetValue) { return new Promise((resolve, reject) => {- const scrollListener = () => {+ const scrollListener = (evt) => { if (getValue() == targetValue) { eventTarget.removeEventListener('scroll', scrollListener);- resolve();+ resolve(evt); } }; if (getValue() == targetValue)@@ -79,4 +95,3 @@ eventTarget.addEventListener('scroll', scrollListener); }); }-
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/css-scroll-snap/support/common.js [Lines] 41-95 [Old Code] Various promise resolutions without parameters (e.g., `resolve()`) [Fixed Code] Promise resolutions now include parameters (e.g., `resolve(time)`, `resolve(evt)`) 2. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/css-scroll-snap/support/common.js [Lines] 55-95 [Old Code] Single-purpose `waitForScrollEvent` function [Fixed Code] Generalized `waitForEvent` function and added `waitForWheelEvent` functionality 3. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/css-scroll-snap/support/common.js [Lines] 79-95 [Old Code] `waitForScrollEnd` function without clear documentation about its limitations [Fixed Code] Added TODO comment clarifying the function's limitations and added `waitForScrollTo` function The changes appear to be primarily about: 1. Improving promise handling by including resolution values 2. Generalizing event waiting functionality 3. Adding documentation about function limitations 4. Adding new functionality (wheel event support) No clear security vulnerabilities were identified in these changes - they seem to be focused on code quality, functionality improvements, and better testing support.
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/compositing/2d.composite.clip.xor.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.clip.xor.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 = '#0f0';@@ -24,8 +24,8 @@ ctx.clip(); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 50, 50);-_assertPixel(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");+_assertPixel(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");+_assertPixel(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, here's my assessment:
Vulnerability Existed: no
[Variable Renaming] [testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.clip.xor.worker.js] [Lines 13-14, 24-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");
_assertPixel(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");
_assertPixel(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");
The changes appear to be purely cosmetic, renaming the variable from `offscreenCanvas` to `canvas` for consistency or readability. There are no security-related changes or vulnerabilities being fixed in this diff. The functionality remains exactly the same, only the variable name has changed.
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/netwerk/protocol/gio/GIOChannelChild.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/netwerk/protocol/gio/GIOChannelChild.cpp@@ -454,8 +454,6 @@ if (!mNeckoTarget) { return; }-- gNeckoChild->SetEventTargetForActor(this, mNeckoTarget); } } // namespace net
Analyzing the provided code diff for security fixes: 1. Vulnerability Existed: not sure [Potential Event Target Manipulation] [netwerk/protocol/gio/GIOChannelChild.cpp] [Lines 454] Old Code: ```cpp gNeckoChild->SetEventTargetForActor(this, mNeckoTarget); ``` Fixed Code: ```cpp // Removed line ``` Additional Details: The removal of this line might be related to preventing potential event target manipulation or incorrect event routing, but without more context about the actor and target usage, this is uncertain. Note: The diff shows removal of a line that sets an event target for an actor. While this could potentially be related to security (like preventing incorrect event routing or privilege escalation), there isn't enough context to definitively identify a specific vulnerability. The change might also be purely architectural rather than security-related.
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.