starsofchance/CVEfixes_v1.0.8 huggingface dataset:
CVE-2013-7262 (published 2014-01-05T20:55Z)

SQL injection vulnerability in the msPostGISLayerSetTimeFilter function in mappostgis.c in MapServer before 6.4.1, when a WMS-Time service is used, allows remote attackers to execute arbitrary SQL commands via a crafted string in a PostGIS TIME filter.

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

Weakness information:
cwe_id: CWE-89
cwe_name: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
description: The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
extended_description: 
            
            
         
         

Fix information:
repo_url: https://github.com/mapserver/mapserver
commit_details: repo_url: https://github.com/mapserver/mapserver
author: Even Rouault
author_date: 2013-12-31 13:54:40+01:00
msg: Fix potential SQL Injection with postgis TIME filters (#4834)
repository: repo_url: https://github.com/mapserver/mapserver
repo_name: MapServer/MapServer
description: Source code of the MapServer project.  Please submit pull requests to the 'main' branch.
repo_language: C
owner: mapserver
file_changes: filename: mappostgis.c
change_type: ModificationType.MODIFY
diff: @@ -3212,6 +3212,11 @@ int msPostGISLayerSetTimeFilter(layerObj *lp, const char *timestring, const char
   if (!lp || !timestring || !timefield)
     return MS_FALSE;
 
+  if( strchr(timestring,'\'') || strchr(timestring, '\\') ) {
+     msSetError(MS_MISCERR, "Invalid time filter.", "msPostGISLayerSetTimeFilter()");
+     return MS_FALSE;
+  }
+
   /* discrete time */
   if (strstr(timestring, ",") == NULL &&
       strstr(timestring, "/") == NULL) { /* discrete time */

programming_language: C
CVE-2019-19058 (published 2019-11-18T06:15Z)

A memory leak in the alloc_sgtable() function in drivers/net/wireless/intel/iwlwifi/fw/dbg.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption) by triggering alloc_page() failures, aka CID-b4b814fec1a5.

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

Weakness information:
cwe_id: CWE-401
cwe_name: Missing Release of Memory after Effective Lifetime
description: The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.
extended_description: This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions.  In some languages, developers are responsible for tracking memory allocation and releasing the memory.  If there are no more pointers or references to the memory, then it can no longer be tracked and identified for release.
         

Fix information:
repo_url: https://github.com/torvalds/linux
commit_details: repo_url: https://github.com/torvalds/linux
author: Navid Emamdoost
author_date: 2019-09-12 23:23:27-05:00
msg: iwlwifi: dbg_ini: fix memory leak in alloc_sgtable

In alloc_sgtable if alloc_page fails, the alocated table should be
released.

Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
repository: repo_url: https://github.com/torvalds/linux
repo_name: torvalds/linux
description: Linux kernel source tree
repo_language: C
owner: torvalds
file_changes: filename: dbg.c
change_type: ModificationType.MODIFY
diff: @@ -646,6 +646,7 @@ static struct scatterlist *alloc_sgtable(int size)
 				if (new_page)
 					__free_page(new_page);
 			}
+			kfree(table);
 			return NULL;
 		}
 		alloc_size = min_t(int, size, PAGE_SIZE);

programming_language: C
CVE-2021-25913 (published 2021-02-08T22:15Z)

Prototype pollution vulnerability in 'set-or-get' version 1.0.0 through 1.2.10 allows an 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: CWE-1321
cwe_name: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
description: The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.
extended_description: 
				By adding or modifying attributes of an object prototype, it is possible to create attributes that exist on every object, or replace critical attributes with malicious ones. This can be problematic if the product depends on existence or non-existence of certain attributes, or uses pre-defined attributes of object prototype (such as hasOwnProperty, toString or valueOf).
				This weakness is usually exploited by using a special attribute of objects called proto,  constructor or prototype. Such attributes give access to the object prototype. This weakness is often found in code that assigns object attributes based on user input, or merges or clones objects recursively.
			
			

Fix information:
repo_url: https://github.com/IonicaBizau/set-or-get.js
commit_details: repo_url: https://github.com/IonicaBizau/set-or-get.js
author: Arjun Shibu
author_date: 2020-12-17 22:52:45+05:30
msg: Security fix for Prototype Pollution
repository: repo_url: https://github.com/IonicaBizau/set-or-get.js
repo_name: IonicaBizau/set-or-get.js
description: :ideograph_advantage: Sets or gets an object field value.
repo_language: JavaScript
owner: IonicaBizau
file_changes: filename: index.js
change_type: ModificationType.MODIFY
diff: @@ -13,6 +13,8 @@ var Deffy = require("deffy");
  * @return {Object|Array} The field value.
  */
 function SetOrGet(input, field, def) {
+    if (field == '__proto__' || field == 'constructor' || field == 'prototype')
+        throw new Error('Restricted setting magical attributes')
     return input[field] = Deffy(input[field], def);
 }
 

programming_language: JavaScript
CVE-2023-34188 (published 2023-06-23T20:15Z)

The HTTP server in Mongoose before 7.10 accepts requests containing negative Content-Length headers. By sending a single attack payload over TCP, an attacker can cause an infinite loop in which the server continuously reparses that payload, and does not respond to any other requests.

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

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/cesanta/mongoose
commit_details: repo_url: https://github.com/cesanta/mongoose
author: Allan Park
author_date: 2023-05-16 15:17:33+03:00
msg: Added check for negative value for HTTP Content-Length header
repository: repo_url: https://github.com/cesanta/mongoose
repo_name: cesanta/mongoose
description: Embedded Web Server
repo_language: C
owner: cesanta
file_changes: filename: mongoose.c
change_type: ModificationType.MODIFY
diff: @@ -1463,7 +1463,9 @@ int mg_http_parse(const char *s, size_t len, struct mg_http_message *hm) {
   mg_http_parse_headers(s, end, hm->headers,
                         sizeof(hm->headers) / sizeof(hm->headers[0]));
   if ((cl = mg_http_get_header(hm, "Content-Length")) != NULL) {
-    hm->body.len = (size_t) mg_to64(*cl);
+    int64_t content_len = mg_to64(*cl);
+    if(content_len < 0) return -1;
+    hm->body.len = (size_t) content_len;
     hm->message.len = (size_t) req_len + hm->body.len;
   }
 

programming_language: C
filename: http.c
change_type: ModificationType.MODIFY
diff: @@ -231,7 +231,9 @@ int mg_http_parse(const char *s, size_t len, struct mg_http_message *hm) {
   mg_http_parse_headers(s, end, hm->headers,
                         sizeof(hm->headers) / sizeof(hm->headers[0]));
   if ((cl = mg_http_get_header(hm, "Content-Length")) != NULL) {
-    hm->body.len = (size_t) mg_to64(*cl);
+    int64_t content_len = mg_to64(*cl);
+    if(content_len < 0) return -1;
+    hm->body.len = (size_t) content_len;
     hm->message.len = (size_t) req_len + hm->body.len;
   }
 

programming_language: C
filename: unit_test.c
change_type: ModificationType.MODIFY
diff: @@ -790,6 +790,10 @@ static void test_http_server(void) {
   ASSERT(fetch(&mgr, buf, url, "GET /..ddot HTTP/1.0\n\n") == 301);
   ASSERT(fetch(&mgr, buf, url, "GET /..ddot/ HTTP/1.0\n\n") == 200);
   ASSERT(cmpbody(buf, "hi\n") == 0);
+  ASSERT(fetch(&mgr, buf, url, "GET /a.txt HTTP/1.0\n"
+        "Content-Length: -123\n\n") == 0);
+  ASSERT(fetch(&mgr, buf, url, "POST /a.txt HTTP/1.0\n"
+               "Content-Length: -123\n\n") == 0);
 
   {
     extern char *mg_http_etag(char *, size_t, size_t, time_t);

programming_language: C++
CVE-2020-15085 (published 2020-06-30T17:15Z)

In Saleor Storefront before version 2.10.3, request data used to authenticate customers was inadvertently cached in the browser's local storage mechanism, including credentials. A malicious user with direct access to the browser could extract the email and password. In versions prior to 2.10.0 persisted the cache even after the user logged out. This is fixed in version 2.10.3. A workaround is to manually clear application data (browser's local storage) after logging into Saleor Storefront.

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

Weakness information:
cwe_id: CWE-312
cwe_name: Cleartext Storage of Sensitive Information
description: The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
extended_description: 
	 Because the information is stored in cleartext (i.e., unencrypted), attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.
	 When organizations adopt cloud services, it can be easier for attackers to access the data from anywhere on the Internet.
	 In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.
       
         

Fix information:
repo_url: https://github.com/mirumee/saleor-storefront
commit_details: repo_url: https://github.com/mirumee/saleor-storefront
author: Patryk Zawadzki
author_date: 2020-06-30 12:44:53+02:00
msg: Merge pull request from GHSA-4279-h39w-2jqm

Do not store passwords in localStorage
repository: repo_url: https://github.com/mirumee/saleor-storefront
repo_name: saleor/saleor-storefront
description: A GraphQL-powered, NextJs-based, PWA storefront for Saleor. IMPORTANT: This project is [DEPRECATED] in favor of saleor/react-storefront soon to become our default demo and storefront starter pack.
repo_language: TypeScript
owner: mirumee
CVE-2021-29514 (published 2021-05-14T20:15Z)

TensorFlow is an end-to-end open source platform for machine learning. If the `splits` argument of `RaggedBincount` does not specify a valid `SparseTensor`(https://www.tensorflow.org/api_docs/python/tf/sparse/SparseTensor), then an attacker can trigger a heap buffer overflow. This will cause a read from outside the bounds of the `splits` tensor buffer in the implementation of the `RaggedBincount` op(https://github.com/tensorflow/tensorflow/blob/8b677d79167799f71c42fd3fa074476e0295413a/tensorflow/core/kernels/bincount_op.cc#L430-L446). Before the `for` loop, `batch_idx` is set to 0. The attacker sets `splits(0)` to be 7, hence the `while` loop does not execute and `batch_idx` remains 0. This then results in writing to `out(-1, bin)`, which is before the heap allocated buffer for the output tensor. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2 and TensorFlow 2.3.3, as these are also affected.

Severity: MEDIUM
CVSS v2 base score: 4.6 (AV:L/AC:L/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 7.8, HIGH (CVSS:3.1/AV:L/AC:L/PR:L/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/tensorflow/tensorflow
commit_details: repo_url: https://github.com/tensorflow/tensorflow
author: Amit Patankar
author_date: 2021-04-13 14:18:51-07:00
msg: Fix an invalid address vulnerability in `tf.raw_ops.RaggedBincount`.

PiperOrigin-RevId: 368293153
Change-Id: I4b4e493d3fd05e7dc55a55de3a041a80a4f275c3
repository: repo_url: https://github.com/tensorflow/tensorflow
repo_name: tensorflow/tensorflow
description: An Open Source Machine Learning Framework for Everyone
repo_language: C++
owner: tensorflow
file_changes: filename: bincount_op.cc
change_type: ModificationType.MODIFY
diff: @@ -420,6 +420,15 @@ class RaggedBincountOp : public OpKernel {
     int num_values = values.size();
     int batch_idx = 0;
 
+    OP_REQUIRES(ctx, splits(0) == 0,
+                errors::InvalidArgument("Splits must start with 0, not with ",
+                                        splits(0)));
+
+    OP_REQUIRES(ctx, splits(num_rows) == num_values,
+                errors::InvalidArgument(
+                    "Splits must end with the number of values, got ",
+                    splits(num_rows), " instead of ", num_values));
+
     Tensor* out_t;
     OP_REQUIRES_OK(
         ctx, ctx->allocate_output(0, TensorShape({num_rows, size}), &out_t));

programming_language: C++
CVE-2017-9201 (published 2017-05-23T04:29Z)

imagew-cmd.c:850:46 in libimageworsener.a in ImageWorsener 1.3.1 allows remote attackers to cause a denial of service (divide-by-zero error) via a crafted image, related to imagew-api.c.

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

Weakness information:
cwe_id: CWE-369
cwe_name: Divide By Zero
description: The product divides a value by zero.
extended_description: This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.
         

Fix information:
repo_url: https://github.com/jsummers/imageworsener
commit_details: repo_url: https://github.com/jsummers/imageworsener
author: Jason Summers
author_date: 2017-05-15 13:27:08-04:00
msg: Double-check that the input image's density is valid

Fixes a bug that could result in division by zero, at least for a JPEG
source image.
Fixes issues #19, #20
repository: repo_url: https://github.com/jsummers/imageworsener
repo_name: jsummers/imageworsener
description: A utility for processing PNG, JPEG, BMP, and WebP images. Features include resize/resample, dither, grayscale, apply background color, subpixel rendering.
repo_language: C
owner: jsummers
file_changes: filename: imagew-api.c
change_type: ModificationType.MODIFY
diff: @@ -483,13 +483,20 @@ IW_IMPL(int) iw_get_input_density(struct iw_context *ctx,
 {
 	*px = 1.0;
 	*py = 1.0;
-	*pcode = ctx->img1.density_code;
-	if(ctx->img1.density_code!=IW_DENSITY_UNKNOWN) {
-		*px = ctx->img1.density_x;
-		*py = ctx->img1.density_y;
-		return 1;
+	*pcode = IW_DENSITY_UNKNOWN;
+
+	if(ctx->img1.density_code==IW_DENSITY_UNKNOWN) {
+		return 0;
 	}
-	return 0;
+	if(!iw_is_valid_density(ctx->img1.density_x, ctx->img1.density_y,
+		ctx->img1.density_code))
+	{
+		return 0;
+	}
+	*px = ctx->img1.density_x;
+	*py = ctx->img1.density_y;
+	*pcode = ctx->img1.density_code;
+	return 1;
 }
 
 IW_IMPL(void) iw_set_output_density(struct iw_context *ctx,

programming_language: C
CVE-2021-37645 (published 2021-08-12T21:15Z)

TensorFlow is an end-to-end open source platform for machine learning. In affected versions the implementation of `tf.raw_ops.QuantizeAndDequantizeV4Grad` is vulnerable to an integer overflow issue caused by converting a signed integer value to an unsigned one and then allocating memory based on this value. The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/quantize_and_dequantize_op.cc#L126) uses the `axis` value as the size argument to `absl::InlinedVector` constructor. But, the constructor uses an unsigned type for the argument, so the implicit conversion transforms the negative value to a large integer. We have patched the issue in GitHub commit 96f364a1ca3009f98980021c4b32be5fdcca33a1. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, and TensorFlow 2.4.3, as these are also affected and still in supported range.

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

Weakness information:
cwe_id: CWE-681
cwe_name: Incorrect Conversion between Numeric Types
description: When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
extended_description: 
            
            
            
         
         

Fix information:
repo_url: https://github.com/tensorflow/tensorflow
commit_details: repo_url: https://github.com/tensorflow/tensorflow
author: Laura Pak
author_date: 2021-08-02 13:27:01-07:00
msg: Validate axis input in tf.raw_ops.QuantizeAndDequantizeV4Grad

PiperOrigin-RevId: 388291385
Change-Id: I3bab68dc61d935afa96c0da021a7b722c6dc8dc8
repository: repo_url: https://github.com/tensorflow/tensorflow
repo_name: tensorflow/tensorflow
description: An Open Source Machine Learning Framework for Everyone
repo_language: C++
owner: tensorflow
file_changes: filename: quantize_and_dequantize_op.cc
change_type: ModificationType.MODIFY
diff: @@ -158,6 +158,13 @@ class QuantizeAndDequantizeV4GradientOp : public OpKernel {
     Tensor* input_backprop = nullptr;
     OP_REQUIRES_OK(ctx,
                    ctx->allocate_output(0, input.shape(), &input_backprop));
+    OP_REQUIRES(
+        ctx, axis_ >= -1,
+        errors::InvalidArgument("Axis must be at least -1. Found ", axis_));
+    OP_REQUIRES(ctx, (axis_ == -1 || axis_ < input.shape().dims()),
+                errors::InvalidArgument(
+                    "Axis should be -1 or 0 or a positive value less than ",
+                    input.shape().dims(), "but given axis value was ", axis_));
 
     OP_REQUIRES(
         ctx, input.IsSameSize(gradient),

programming_language: C++
CVE-2020-28194 (published 2021-02-01T14:15Z)

Variable underflow exists in accel-ppp radius/packet.c when receiving a RADIUS vendor-specific attribute with length field is less than 2. It has an impact only when the attacker controls the RADIUS server, which can lead to arbitrary 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: CWE-191
cwe_name: Integer Underflow (Wrap or Wraparound)
description: The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.
extended_description: This can happen in signed and unsigned cases.
         

Fix information:
repo_url: https://github.com/accel-ppp/accel-ppp
commit_details: repo_url: https://github.com/accel-ppp/accel-ppp
author: Dmitry Kozlov
author_date: 2020-10-21 12:40:26+03:00
msg: radius: sanity check for vendor attribute length
repository: repo_url: https://github.com/accel-ppp/accel-ppp
repo_name: accel-ppp/accel-ppp
description: High performance PPTP/L2TP/SSTP/PPPoE/IPoE server for Linux
repo_language: C
owner: accel-ppp
file_changes: filename: packet.c
change_type: ModificationType.MODIFY
diff: @@ -206,6 +206,14 @@ int rad_packet_recv(int fd, struct rad_packet_t **p, struct sockaddr_in *addr)
 				len -= vendor->tag + vendor->len;
 
 				n -= 4 + vendor->tag + vendor->len;
+				if (len < 0) {
+					log_ppp_warn("radius:packet invalid vendor attribute len received\n");
+					goto out_err;
+				}
+				if (2 + len > n) {
+					log_ppp_warn("radius:packet: too long vendor attribute received (%i, %i)\n", id, len);
+					goto out_err;
+				}
 			} else
 				log_ppp_warn("radius:packet: vendor %i not found\n", id);
 		} else

programming_language: C
CVE-2023-35846 (published 2023-06-19T03:15Z)

VirtualSquare picoTCP (aka PicoTCP-NG) through 2.1 does not check the transport layer length in a frame before performing port filtering.

CVSS v3 base score: 7.5, HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/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/virtualsquare/picotcp
commit_details: repo_url: https://github.com/virtualsquare/picotcp
author: Daniele Lacamera
author_date: 2023-05-12 22:24:23+02:00
msg: [ipfilter] Check transport layer length in frame before filtering ports

Reported-by: "P. Amsuo, Purdue University"
repository: repo_url: https://github.com/virtualsquare/picotcp
repo_name: virtualsquare/picotcp
repo_language: C
owner: virtualsquare
file_changes: filename: pico_ipfilter.c
change_type: ModificationType.MODIFY
diff: @@ -461,18 +461,18 @@ int ipfilter(struct pico_frame *f)
     temp.fdev = f->dev;
     temp.out_addr = ipv4_hdr->dst.addr;
     temp.in_addr = ipv4_hdr->src.addr;
-    if ((ipv4_hdr->proto == PICO_PROTO_TCP) || (ipv4_hdr->proto == PICO_PROTO_UDP)) {
-        trans = (struct pico_trans *) f->transport_hdr;
-        temp.out_port = short_be(trans->dport);
-        temp.in_port = short_be(trans->sport);
-    }
-    else if(ipv4_hdr->proto == PICO_PROTO_ICMP4) {
-        icmp_hdr = (struct pico_icmp4_hdr *) f->transport_hdr;
-        if(icmp_hdr->type == PICO_ICMP_UNREACH && icmp_hdr->code == PICO_ICMP_UNREACH_FILTER_PROHIB)
-            return 0;
+    if ((f->transport_hdr + sizeof(struct pico_trans)) <= (f->buffer + f->buffer_len)) {
+        if ((ipv4_hdr->proto == PICO_PROTO_TCP) || (ipv4_hdr->proto == PICO_PROTO_UDP)) {
+                trans = (struct pico_trans *) f->transport_hdr;
+                temp.out_port = short_be(trans->dport);
+                temp.in_port = short_be(trans->sport);
+        } else if(ipv4_hdr->proto == PICO_PROTO_ICMP4) {
+            icmp_hdr = (struct pico_icmp4_hdr *) f->transport_hdr;
+            if(icmp_hdr->type == PICO_ICMP_UNREACH && icmp_hdr->code == PICO_ICMP_UNREACH_FILTER_PROHIB)
+                return 0;
+        }
+        temp.proto = ipv4_hdr->proto;
     }
-
-    temp.proto = ipv4_hdr->proto;
     temp.priority = f->priority;
     temp.tos = ipv4_hdr->tos;
     return ipfilter_apply_filter(f, &temp);

programming_language: C