starsofchance/CVEfixes_v1.0.8 huggingface dataset:
CVE-2022-30767 (published 2022-05-16T03:15Z)

nfs_lookup_reply in net/nfs.c in Das U-Boot through 2022.04 (and through 2022.07-rc2) has an unbounded memcpy with a failed length check, leading to a buffer overflow. NOTE: this issue exists because of an incorrect fix for CVE-2019-14196.

Severity: HIGH
CVSS v2 base score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 9.8, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-120
cwe_name: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
description: The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
extended_description: A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.
         

Fix information:
repo_url: https://github.com/u-boot/u-boot
commit_details: repo_url: https://github.com/u-boot/u-boot
author: liucheng (G)
author_date: 2019-08-29 13:48:02+00:00
msg: CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at nfs_lookup_reply

This patch adds a check to rpc_pkt.u.reply.data at nfs_lookup_reply.

Signed-off-by: Cheng Liu <liucheng32@huawei.com>
Reported-by: Fermín Serna <fermin@semmle.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
repository: repo_url: https://github.com/u-boot/u-boot
repo_name: u-boot/u-boot
description: "Das U-Boot" Source Tree
repo_language: C
owner: u-boot
file_changes: filename: nfs.c
change_type: ModificationType.MODIFY
diff: @@ -566,11 +566,15 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len)
 	}
 
 	if (supported_nfs_versions & NFSV2_FLAG) {
+		if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + NFS_FHSIZE) > len)
+			return -NFS_RPC_DROP;
 		memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
 	} else {  /* NFSV3_FLAG */
 		filefh3_length = ntohl(rpc_pkt.u.reply.data[1]);
 		if (filefh3_length > NFS3_FHSIZE)
 			filefh3_length  = NFS3_FHSIZE;
+		if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + filefh3_length) > len)
+			return -NFS_RPC_DROP;
 		memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length);
 	}
 

programming_language: C
CVE-2017-12858 (published 2017-08-23T14:29Z)

Double free vulnerability in the _zip_dirent_read function in zip_dirent.c in libzip allows attackers to have unspecified impact via unknown vectors.

Severity: HIGH
CVSS v2 base score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 9.8, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-415
cwe_name: Double Free
description: The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.
extended_description: When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.
         

Fix information:
repo_url: https://github.com/nih-at/libzip
commit_details: repo_url: https://github.com/nih-at/libzip
author: Thomas Klausner
author_date: 2017-08-14 10:55:44+02:00
msg: Fix double free().

Found by Brian 'geeknik' Carpenter using AFL.
repository: repo_url: https://github.com/nih-at/libzip
repo_name: nih-at/libzip
description: A C library for reading, creating, and modifying zip archives.
repo_language: C
owner: nih-at
file_changes: filename: THANKS
change_type: ModificationType.MODIFY
diff: @@ -12,6 +12,7 @@ BALATON Zoltan <balaton@eik.bme.hu>
 Benjamin Gilbert <bgilbert@backtick.net>
 Boaz Stolk <bstolk@aweta.nl>
 Bogdan <bogiebog@gmail.com>
+Brian 'geeknik' Carpenter <geeknik@protonmail.ch>
 Chris Nehren <cnehren+libzip@pobox.com>
 Coverity <info@coverity.com>
 Dane Springmeyer <dane.springmeyer@gmail.com>

programming_language: Markdown
filename: zip_dirent.c
change_type: ModificationType.MODIFY
diff: @@ -579,9 +579,6 @@ _zip_dirent_read(zip_dirent_t *zde, zip_source_t *src, zip_buffer_t *buffer, boo
     }
 
     if (!_zip_dirent_process_winzip_aes(zde, error)) {
-	if (!from_buffer) {
-	    _zip_buffer_free(buffer);
-	}
 	return -1;
     }
 

programming_language: C
CVE-2018-20760 (published 2019-02-06T23:29Z)

In GPAC 0.7.1 and earlier, gf_text_get_utf8_line in media_tools/text_import.c in libgpac_static.a allows an out-of-bounds write because a certain -1 return value is mishandled.

Severity: MEDIUM
CVSS v2 base score: 6.8 (AV:N/AC:M/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 7.8, HIGH (CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-787
cwe_name: Out-of-bounds Write
description: The product writes data past the end, or before the beginning, of the intended buffer.
extended_description: 
            
            
             
			 
         
         

Fix information:
repo_url: https://github.com/gpac/gpac
commit_details: repo_url: https://github.com/gpac/gpac
author: Aurelien David
author_date: 2018-12-13 14:39:21+01:00
msg: check error code on call to gf_utf8_wcstombs (#1177)
repository: repo_url: https://github.com/gpac/gpac
repo_name: gpac/gpac
description: GPAC Ultramedia OSS for Video Streaming & Next-Gen Multimedia Transcoding, Packaging & Delivery
repo_language: C
owner: gpac
file_changes: filename: text_import.c
change_type: ModificationType.MODIFY
diff: @@ -269,6 +269,8 @@ char *gf_text_get_utf8_line(char *szLine, u32 lineSize, FILE *txt_in, s32 unicod
 	}
 	sptr = (u16 *)szLine;
 	i = (u32) gf_utf8_wcstombs(szLineConv, 1024, (const unsigned short **) &sptr);
+	if (i >= (u32)ARRAY_LENGTH(szLineConv))
+		return NULL;
 	szLineConv[i] = 0;
 	strcpy(szLine, szLineConv);
 	/*this is ugly indeed: since input is UTF16-LE, there are many chances the fgets never reads the \0 after a \n*/

programming_language: C
CVE-2020-28274 (published 2020-12-08T22:15Z)

Prototype pollution vulnerability in 'deepref' versions 1.1.1 through 1.2.1 allows attacker to cause a denial of service and may lead to remote code execution.

Severity: HIGH
CVSS v2 base score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 9.8, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: NVD-CWE-noinfo
cwe_name: Insufficient Information
description: There is insufficient information about the issue to classify it; details are unkown or unspecified.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/isaymatato/deepref
commit_details: repo_url: https://github.com/isaymatato/deepref
author: Mateo Williford
author_date: 2020-11-23 09:28:03-06:00
msg: Disallow __proto__ assignment

Disallow assignment to the prototype using `set()`.

This resolves a Prototype Pollution vulnerability. An attacker could
have assigned a value to the target object's prototype, which can modify
how objects behave throughout the entire application.
repository: repo_url: https://github.com/isaymatato/deepref
repo_name: isaymatato/deepref
description: Write to a deeply nested field with a string reference (i.e. "object.subfield.subfield.0")
repo_language: JavaScript
owner: isaymatato
file_changes: filename: index.js
change_type: ModificationType.MODIFY
diff: @@ -55,6 +55,10 @@ Reference.createFromPath = function(pointer, path) {
   var reference = new Reference(pointer);
   path = path.split('.');
   path.forEach(function(field) {
+    if (field === '__proto__') {
+      throw new Error('Cannot assign reference to prototype')
+    }
+
     var isNumber = checkIfStringIsNumber(field);
     var hasParent = reference.getParent() ? true : false;
     if (isNumber) {

programming_language: JavaScript
filename: index.js
change_type: ModificationType.MODIFY
diff: @@ -42,6 +42,14 @@ describe('#set', function() {
     obj.a[1].should.equal('B');
     obj.a[2].should.equal('C');
   });
+
+  context('attempt to modify prototype', function() {
+    it('throws an error', function() {
+      assert.throws(
+        () => set({}, '__proto__.foo', 'hacker_attack!'),
+        Error, 'Cannot assign reference to prototype')
+    })
+  })
 });
 
 describe('#decorate', function() {
@@ -67,4 +75,4 @@ describe('#undecorate', function() {
     undecorate(obj);
     expect(obj.setKey).to.not.be.a('function');
   });
-});
\ No newline at end of file
+});

programming_language: JavaScript
CVE-2020-28495 (published 2021-02-02T11:15Z)

This affects the package total.js before 3.4.7. The set function can be used to set a value into the object according to the path. However the keys of the path being set are not properly sanitized, leading to a prototype pollution vulnerability. The impact depends on the application. In some cases it is possible to achieve Denial of service (DoS), Remote Code Execution or Property Injection.

Severity: HIGH
CVSS v2 base score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 7.3, HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L)

Weakness information:
cwe_id: NVD-CWE-Other
cwe_name: Other
description: NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/totaljs/framework
commit_details: repo_url: https://github.com/totaljs/framework
author: Peter Sirka
author_date: 2020-12-31 11:41:21+01:00
msg: Fixed `U.set()` by adding check for `Prototype pollution`.
repository: repo_url: https://github.com/totaljs/framework
repo_name: totaljs/framework
description: Node.js framework
repo_language: JavaScript
owner: totaljs
file_changes: filename: utils.js
change_type: ModificationType.MODIFY
diff: @@ -6621,6 +6621,10 @@ exports.set = function(obj, path, value) {
 	var v = arr[arr.length - 1];
 	var ispush = v.lastIndexOf('[]') !== -1;
 	var a = builder.join(';') + ';var v=typeof(a)===\'function\'?a(U.get(b)):a;w' + (v[0] === '[' ? '' : '.') + (ispush ? v.replace(REGREPLACEARR, '.push(v)') : (v + '=v')) + ';return v';
+
+	if ((/__proto__|constructor|prototype/).test(a))
+		throw new Error('Prototype pollution');
+
 	var fn = new Function('w', 'a', 'b', a);
 	F.temporary.other[cachekey] = fn;
 	fn(obj, value, path);

programming_language: JavaScript
CVE-2021-3850 (published 2022-01-25T15:15Z)

Authentication Bypass by Primary Weakness in GitHub repository adodb/adodb prior to 5.20.21.

Severity: MEDIUM
CVSS v2 base score: 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N)
CVSS v3 base score: 9.1, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)

Weakness information:
cwe_id: CWE-287
cwe_name: Improper Authentication
description: When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
extended_description: 
            
			
         
         

Fix information:
repo_url: https://github.com/adodb/adodb
commit_details: repo_url: https://github.com/adodb/adodb
author: Damien Regad
author_date: 2022-01-10 09:41:32+01:00
msg: Prevent auth bypass with PostgreSQL connections

Thanks to Emmet Leahy of Sorcery Ltd for reporting this vulnerability
(CVE-2021-3850).

This is a minimalistic approach to patch the issue, to reduce the risk
of causing regressions in the legacy stable branch.

Fixes #793
repository: repo_url: https://github.com/adodb/adodb
repo_name: ADOdb/ADOdb
description: ADOdb is a PHP database class library that provides powerful abstractions for performing queries and managing databases. ADOdb also hides the differences between DB engines so you can easily switch them without changing your code.
repo_language: PHP
owner: adodb
file_changes: filename: adodb-postgres64.inc.php
change_type: ModificationType.MODIFY
diff: @@ -51,7 +51,6 @@ function adodb_addslashes($s)
 {
 	$len = strlen($s);
 	if ($len == 0) return "''";
-	if (strncmp($s,"'",1) === 0 && substr($s,$len-1) == "'") return $s; // already quoted
 
 	return "'".addslashes($s)."'";
 }

programming_language: PHP
CVE-2020-36400 (published 2021-07-01T03:15Z)

ZeroMQ libzmq 4.3.3 has a heap-based buffer overflow in zmq::tcp_read, a different vulnerability than CVE-2021-20235.

Severity: HIGH
CVSS v2 base score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 9.8, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-787
cwe_name: Out-of-bounds Write
description: The product writes data past the end, or before the beginning, of the intended buffer.
extended_description: 
            
            
             
			 
         
         

Fix information:
repo_url: https://github.com/zeromq/libzmq
commit_details: repo_url: https://github.com/zeromq/libzmq
author: Luca Boccassi
author_date: 2020-05-07 00:19:40+01:00
msg: Problem: ZMTP v1 static allocator is needlessly resized

Solution: don't do it, resizing the shared allocator makes sense
as it can take the message buff for zero copy, but the static allocator
is fixed
repository: repo_url: https://github.com/zeromq/libzmq
repo_name: zeromq/libzmq
description: ZeroMQ core engine in C++, implements ZMTP/3.1
repo_language: C++
owner: zeromq
file_changes: filename: decoder_allocators.hpp
change_type: ModificationType.MODIFY
diff: @@ -58,7 +58,8 @@ class c_single_allocator
 
     std::size_t size () const { return _buf_size; }
 
-    void resize (std::size_t new_size_) { _buf_size = new_size_; }
+    //  This buffer is fixed, size must not be changed
+    void resize (std::size_t new_size_) { LIBZMQ_UNUSED (new_size_); }
 
   private:
     std::size_t _buf_size;

programming_language: C++
CVE-2017-15730 (published 2017-10-22T18:29Z)

In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) in admin/stat.ratings.php.

Severity: MEDIUM
CVSS v2 base score: 6.8 (AV:N/AC:M/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 8.8, HIGH (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-352
cwe_name: Cross-Site Request Forgery (CSRF)
description: The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
extended_description: When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or unintended code execution.
         

Fix information:
repo_url: https://github.com/thorsten/phpMyFAQ
commit_details: repo_url: https://github.com/thorsten/phpMyFAQ
author: Thorsten Rinne
author_date: 2017-09-27 19:31:16+02:00
msg: Fixed possible direct calls
repository: repo_url: https://github.com/thorsten/phpMyFAQ
repo_name: thorsten/phpMyFAQ
description: phpMyFAQ - Open Source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases
repo_language: PHP
owner: thorsten
file_changes: filename: stat.ratings.php
change_type: ModificationType.MODIFY
diff: @@ -41,7 +41,8 @@ if ($user->perm->checkRight($user->getUserId(), 'viewlog')) {
                     <i aria-hidden="true" class="fa fa-tasks"></i> <?php echo $PMF_LANG['ad_rs'] ?>
 
                     <div class="pull-right">
-                        <a class="btn btn-danger" href="?action=clear-statistics">
+                        <a class="btn btn-danger" 
+                           href="?action=clear-statistics&csrf=<?php echo $user->getCsrfTokenFromSession() ?>">
                             <i aria-hidden="true" class="fa fa-trash"></i> <?php echo $PMF_LANG['ad_delete_all_votings'] ?>
                         </a>
                     </div>
@@ -50,7 +51,15 @@ if ($user->perm->checkRight($user->getUserId(), 'viewlog')) {
         </header>
 
 <?php
-    if ('clear-statistics' === $action) {
+    $csrfToken = PMF_Filter::filterInput(INPUT_GET, 'csrf', FILTER_SANITIZE_STRING);
+
+    if (!isset($_SESSION['phpmyfaq_csrf_token']) || $_SESSION['phpmyfaq_csrf_token'] !== $csrfToken) {
+        $clearStatistics = false;
+    } else {
+        $clearStatistics = true;
+    }
+
+    if ('clear-statistics' === $action && $clearStatistics) {
         if ($ratings->deleteAll()) {
             echo '<p class="alert alert-success">Statistics successfully deleted.</p>';
         } else {

programming_language: PHP
CVE-2024-25714 (published 2024-02-11T03:15Z)

In Rhonabwy through 1.1.13, HMAC signature verification uses a strcmp function that is vulnerable to side-channel attacks, because it stops the comparison when the first difference is spotted in the two signatures. (The fix uses gnutls_memcmp, which has constant-time execution.)


Weakness information:
cwe_id: NVD-CWE-noinfo
cwe_name: Insufficient Information
description: There is insufficient information about the issue to classify it; details are unkown or unspecified.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/babelouest/rhonabwy
commit_details: repo_url: https://github.com/babelouest/rhonabwy
author: Nicolas Mora
author_date: 2024-02-05 17:26:23-05:00
msg: Mitigate HMAC signature side-channel attack

Thanks to Erwan Legrand
repository: repo_url: https://github.com/babelouest/rhonabwy
repo_name: babelouest/rhonabwy
description: Javascript Object Signing and Encryption (JOSE) library - JWK, JWKS, JWS, JWE and JWT
repo_language: C
owner: babelouest
file_changes: filename: jws.c
change_type: ModificationType.MODIFY
diff: @@ -479,7 +479,10 @@ static int r_jws_verify_sig_hmac(jws_t * jws, jwk_t * jwk) {
   unsigned char * sig = r_jws_sign_hmac(jws, jwk);
   int ret;
 
-  if (sig != NULL && 0 == o_strcmp((const char *)jws->signature_b64url, (const char *)sig)) {
+  if (!o_strnullempty((const char *)jws->signature_b64url) &&
+      !o_strnullempty((const char *)sig) &&
+      o_strlen((const char *)sig) == o_strlen((const char *)jws->signature_b64url) &&
+      0 == gnutls_memcmp(jws->signature_b64url, sig, o_strlen((const char *)sig))) {
     ret = RHN_OK;
   } else {
     ret = RHN_ERROR_INVALID;

programming_language: C
CVE-2020-15084 (published 2020-06-30T16:15Z)

In express-jwt (NPM package) up and including version 5.3.3, the algorithms entry to be specified in the configuration is not being enforced. When algorithms is not specified in the configuration, with the combination of jwks-rsa, it may lead to authorization bypass. You are affected by this vulnerability if all of the following conditions apply: - You are using express-jwt - You do not have **algorithms** configured in your express-jwt configuration. - You are using libraries such as jwks-rsa as the **secret**. You can fix this by specifying **algorithms** in the express-jwt configuration. See linked GHSA for example. This is also fixed in version 6.0.0.

Severity: MEDIUM
CVSS v2 base score: 4.3 (AV:N/AC:M/Au:N/C:N/I:P/A:N)
CVSS v3 base score: 9.1, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)

Weakness information:
cwe_id: CWE-863
cwe_name: Incorrect Authorization
description: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions.
extended_description: 
            Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
            When access control checks are incorrectly applied, users are able to access data or perform actions that they should not be allowed to perform. This can lead to a wide range of problems, including information exposures, denial of service, and arbitrary code execution.
         
         

Fix information:
repo_url: https://github.com/auth0/express-jwt
commit_details: repo_url: https://github.com/auth0/express-jwt
author: Marcos Castany
author_date: 2020-06-29 16:36:49-03:00
msg: Merge pull request from GHSA-6g6m-m6h5-w9gf

Made algorithms mandatory
repository: repo_url: https://github.com/auth0/express-jwt
repo_name: auth0/express-jwt
description: connect/express middleware that validates a JsonWebToken (JWT) and set the req.user with the attributes
repo_language: TypeScript
owner: auth0
CVE-2013-7008 (published 2013-12-09T16:36Z)

The decode_slice_header function in libavcodec/h264.c in FFmpeg before 2.1 incorrectly relies on a certain droppable field, which allows remote attackers to cause a denial of service (deadlock) or possibly have unspecified other impact via crafted H.264 data.

Severity: MEDIUM
CVSS v2 base score: 6.8 (AV:N/AC:M/Au:N/C:P/I:P/A:P)

Weakness information:
cwe_id: NVD-CWE-Other
cwe_name: Other
description: NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/FFmpeg/FFmpeg
commit_details: repo_url: https://github.com/FFmpeg/FFmpeg
author: Michael Niedermayer
author_date: 2013-10-24 23:11:41+02:00
msg: avcodec/h264: do not trust last_pic_droppable when marking pictures as done

This simplifies the code and fixes a deadlock

Fixes Ticket2927
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
repository: repo_url: https://github.com/FFmpeg/FFmpeg
repo_name: FFmpeg/FFmpeg
description: Mirror of https://git.ffmpeg.org/ffmpeg.git
repo_language: C
owner: FFmpeg
file_changes: filename: h264.c
change_type: ModificationType.MODIFY
diff: @@ -3621,7 +3621,7 @@ static int decode_slice_header(H264Context *h, H264Context *h0)
             assert(h0->cur_pic_ptr->reference != DELAYED_PIC_REF);
 
             /* Mark old field/frame as completed */
-            if (!last_pic_droppable && h0->cur_pic_ptr->tf.owner == h0->avctx) {
+            if (h0->cur_pic_ptr->tf.owner == h0->avctx) {
                 ff_thread_report_progress(&h0->cur_pic_ptr->tf, INT_MAX,
                                           last_pic_structure == PICT_BOTTOM_FIELD);
             }
@@ -3630,7 +3630,7 @@ static int decode_slice_header(H264Context *h, H264Context *h0)
             if (!FIELD_PICTURE(h) || h->picture_structure == last_pic_structure) {
                 /* Previous field is unmatched. Don't display it, but let it
                  * remain for reference if marked as such. */
-                if (!last_pic_droppable && last_pic_structure != PICT_FRAME) {
+                if (last_pic_structure != PICT_FRAME) {
                     ff_thread_report_progress(&h0->cur_pic_ptr->tf, INT_MAX,
                                               last_pic_structure == PICT_TOP_FIELD);
                 }
@@ -3640,7 +3640,7 @@ static int decode_slice_header(H264Context *h, H264Context *h0)
                      * different frame_nums. Consider this field first in
                      * pair. Throw away previous field except for reference
                      * purposes. */
-                    if (!last_pic_droppable && last_pic_structure != PICT_FRAME) {
+                    if (last_pic_structure != PICT_FRAME) {
                         ff_thread_report_progress(&h0->cur_pic_ptr->tf, INT_MAX,
                                                   last_pic_structure == PICT_TOP_FIELD);
                     }

programming_language: C