rufimelo/DeltaSecommits huggingface dataset:
Vulnerability: Weave GitOps leaked cluster credentials into logs on connection errors ### Impact
A vulnerability in the logging of Weave GitOps could allow an authenticated remote attacker to view sensitive cluster configurations, aka KubeConfg, of registered Kubernetes clusters, including the service account tokens in plain text from Weave GitOps's pod logs on the management cluster. An unauthorized remote attacker can also view these sensitive configurations from external log storage if enabled by the management cluster.

This vulnerability is due to the client factory dumping cluster configurations and their service account tokens when the cluster manager tries to connect to an API server of a registered cluster, and a connection error occurs. An attacker could exploit this vulnerability by either accessing logs of a pod of Weave GitOps, or from external log storage and obtaining all cluster configurations of registered clusters.

A successful exploit could allow the attacker to use those cluster configurations to manage the registered Kubernetes clusters.

### Patches
This vulnerability has been fixed by commit 567356f471353fb5c676c77f5abc2a04631d50ca. Users should upgrade to Weave GitOps core version >= v0.8.1-rc.6 released on 31/05/2022.

### Workarounds
There is no workaround for this vulnerability.

### References
Disclosed by Stefan Prodan, Principal Engineer, Weaveworks.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [Weave GitOps repository](https://github.com/weaveworks/weave-gitops)
* Email us at [support@weave.works](mailto:support@weave.works)
Vulnerability ID: GHSA-xggc-qprg-x6mw
CWE: CWE-200
Severity score: 9
Project: https://github.com/weaveworks/weave-gitops
Published: 2022-06-23
File: core/clustersmngr/factory.go
Commit message: Fix logging on cluster connection error
Remove the client config from the error log since the wrapped error already contains the cluster name for which the connection couldn't be established.

Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
Commit author: Stefan Prodan

Vulnerable version (before fix):
 func (cf *clientsFactory) watchNamespaces(ctx context.Context) { func (cf *clientsFactory) UpdateNamespaces(ctx context.Context) error { 	clients, err := clientsForClusters(cf.clusters.Get()) 	if err != nil { 		cf.log.Error(err, "failed to create clients for", "clusters", cf.clusters.Get()) 		return err 	} 

Fixed version (after fix):
 func (cf *clientsFactory) watchNamespaces(ctx context.Context) { func (cf *clientsFactory) UpdateNamespaces(ctx context.Context) error { 	clients, err := clientsForClusters(cf.clusters.Get()) 	if err != nil { 		cf.log.Error(err, "failed to create client") 		return err 	} 

Patch:
patch: @@ -131,7 +131,7 @@ func (cf *clientsFactory) watchNamespaces(ctx context.Context) {
 func (cf *clientsFactory) UpdateNamespaces(ctx context.Context) error {
 	clients, err := clientsForClusters(cf.clusters.Get())
 	if err != nil {
-		cf.log.Error(err, "failed to create clients for", "clusters", cf.clusters.Get())
+		cf.log.Error(err, "failed to create client")
 		return err
 	}
path: core/clustersmngr/factory.go
Vulnerability: Data Flow Sanitation Issue Fix  ### Impact
Due to missing sanitation in data flow it was possible for admin users to upload arbitrary executable files to the server.
Vulnerability ID: GHSA-xm9f-vxmx-4m58
CWE: CWE-20
Severity score: 0
Project: https://github.com/OpenMage/magento-lts
Published: 2021-08-30
File: app/code/core/Mage/Dataflow/Model/Convert/Adapter/Io.php
Commit message: Merge pull request from GHSA-xm9f-vxmx-4m58

Co-authored-by: Mark Lewis <markwlewis@Marks-MacBook-Pro.local>
Commit author: Mark Lewis

Vulnerable version (before fix):
 public function getResource($forWrite = false)             $isError = false;              $ioConfig = $this->getVars();             switch ($this->getVar('type', 'file')) {                 case 'file':                     //validate export/import path                     $path = rtrim($ioConfig['path'], '\\/')

Fixed version (after fix):
 public function getResource($forWrite = false)             $isError = false;              $ioConfig = $this->getVars();             switch (strtolower($this->getVar('type', 'file'))) {                 case 'file':                     //validate export/import path                     $path = rtrim($ioConfig['path'], '\\/')

Patch:
patch: @@ -49,7 +49,7 @@ public function getResource($forWrite = false)
             $isError = false;
 
             $ioConfig = $this->getVars();
-            switch ($this->getVar('type', 'file')) {
+            switch (strtolower($this->getVar('type', 'file'))) {
                 case 'file':
                     //validate export/import path
                     $path = rtrim($ioConfig['path'], '\\/')
path: app/code/core/Mage/Dataflow/Model/Convert/Adapter/Io.php
Vulnerability: In the Linux kernel before 2.6.20, there is an off-by-one bug in net/netlabel/netlabel_cipso_v4.c where it is possible to overflow the doi_def->tags[] array.
Vulnerability ID: CVE-2007-6762
CWE: CWE-119
Severity score: 6.4
Project: https://github.com/torvalds/linux
Published: 2019-07-27
File: net/netlabel/netlabel_cipso_v4.c
Commit message: NetLabel: correct CIPSO tag handling when adding new DOI definitions

The current netlbl_cipsov4_add_common() function has two problems which are
fixed with this patch.  The first is an off-by-one bug where it is possibile to
overflow the doi_def->tags[] array.  The second is a bug where the same
doi_def->tags[] array was not always fully initialized, which caused sporadic
failures.

Signed-off-by: Paul Moore <paul.moore@hp.com>
Signed-off-by: James Morris <jmorris@namei.org>
Commit author: Paul Moore

Vulnerable version (before fix):
 static int netlbl_cipsov4_add_common(struct genl_info *info,  	nla_for_each_nested(nla, info->attrs[NLBL_CIPSOV4_A_TAGLST], nla_rem) 		if (nla->nla_type == NLBL_CIPSOV4_A_TAG) { 			if (iter > CIPSO_V4_TAG_MAXCNT) 				return -EINVAL; 			doi_def->tags[iter++] = nla_get_u8(nla); 		} 	if (iter < CIPSO_V4_TAG_MAXCNT) 		doi_def->tags[iter] = CIPSO_V4_TAG_INVALID;  	return 0; }

Fixed version (after fix):
 static int netlbl_cipsov4_add_common(struct genl_info *info,  	nla_for_each_nested(nla, info->attrs[NLBL_CIPSOV4_A_TAGLST], nla_rem) 		if (nla->nla_type == NLBL_CIPSOV4_A_TAG) { 			if (iter >= CIPSO_V4_TAG_MAXCNT) 				return -EINVAL; 			doi_def->tags[iter++] = nla_get_u8(nla); 		} 	while (iter < CIPSO_V4_TAG_MAXCNT) 		doi_def->tags[iter++] = CIPSO_V4_TAG_INVALID;  	return 0; }

Patch:
patch: @@ -130,12 +130,12 @@ static int netlbl_cipsov4_add_common(struct genl_info *info,
 
 	nla_for_each_nested(nla, info->attrs[NLBL_CIPSOV4_A_TAGLST], nla_rem)
 		if (nla->nla_type == NLBL_CIPSOV4_A_TAG) {
-			if (iter > CIPSO_V4_TAG_MAXCNT)
+			if (iter >= CIPSO_V4_TAG_MAXCNT)
 				return -EINVAL;
 			doi_def->tags[iter++] = nla_get_u8(nla);
 		}
-	if (iter < CIPSO_V4_TAG_MAXCNT)
-		doi_def->tags[iter] = CIPSO_V4_TAG_INVALID;
+	while (iter < CIPSO_V4_TAG_MAXCNT)
+		doi_def->tags[iter++] = CIPSO_V4_TAG_INVALID;
 
 	return 0;
 }
path: net/netlabel/netlabel_cipso_v4.c
Vulnerability: Integer overflow in the pango_glyph_string_set_size function in pango/glyphstring.c in Pango before 1.24 allows context-dependent attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a long glyph string that triggers a heap-based buffer overflow, as demonstrated by a long document.location value in Firefox.
Vulnerability ID: CVE-2009-1194
CWE: CWE-189
Severity score: 6.4
Project: http://github.com/bratsche/pango
Published: 2009-05-11
File: pango/glyphstring.c
Commit message: [glyphstring] Handle overflow with very long glyphstrings
Commit author: Behdad Esfahbod

Vulnerable version (before fix):
 pango_glyph_string_set_size (PangoGlyphString *string, gint new_len)   while (new_len > string->space)     {       if (string->space == 0) 	string->space = 1;       else 	string->space *= 2;        if (string->space < 0) 	{ 	  g_warning ("glyph string length overflows maximum integer size, truncated"); 	  new_len = string->space = G_MAXINT - 8; 	}     } 

Fixed version (after fix):
 pango_glyph_string_set_size (PangoGlyphString *string, gint new_len)   while (new_len > string->space)     {       if (string->space == 0) 	{ 	  string->space = 4; 	}       else 	{ 	  const guint max_space = 	    MIN (G_MAXINT, G_MAXSIZE / MAX (sizeof(PangoGlyphInfo), sizeof(gint)));  	  guint more_space = (guint)string->space * 2;  	  if (more_space > max_space) 	    { 	      more_space = max_space;  	      if ((guint)new_len > max_space) 		{ 		  g_error ("%s: failed to allocate glyph string of length %i\n", 			   G_STRLOC, new_len); 		} 	    }  	  string->space = more_space; 	}     } 

Patch:
patch: @@ -61,14 +61,28 @@ pango_glyph_string_set_size (PangoGlyphString *string, gint new_len)
   while (new_len > string->space)
     {
       if (string->space == 0)
-	string->space = 1;
+	{
+	  string->space = 4;
+	}
       else
-	string->space *= 2;
-
-      if (string->space < 0)
 	{
-	  g_warning ("glyph string length overflows maximum integer size, truncated");
-	  new_len = string->space = G_MAXINT - 8;
+	  const guint max_space =
+	    MIN (G_MAXINT, G_MAXSIZE / MAX (sizeof(PangoGlyphInfo), sizeof(gint)));
+
+	  guint more_space = (guint)string->space * 2;
+
+	  if (more_space > max_space)
+	    {
+	      more_space = max_space;
+
+	      if ((guint)new_len > max_space)
+		{
+		  g_error ("%s: failed to allocate glyph string of length %i\n",
+			   G_STRLOC, new_len);
+		}
+	    }
+
+	  string->space = more_space;
 	}
     }
path: pango/glyphstring.c
Vulnerability: The fr_dhcp_decode function in lib/dhcp.c in FreeRADIUS 2.1.9, in certain non-default builds, does not properly handle the DHCP Relay Agent Information option, which allows remote attackers to cause a denial of service (infinite loop and daemon outage) via a packet that has more than one sub-option.  NOTE: some of these details are obtained from third party information.
Vulnerability ID: CVE-2010-3696
CWE: CWE-399
Severity score: 2.9
Project: http://github.com/alandekok/freeradius-server
Published: 2010-10-07
File: src/lib/dhcp.c
Commit message: Fix endless loop when there are multiple DHCP options
Commit author: Alan T. DeKok

Vulnerable version (before fix):
 int fr_dhcp_decode(RADIUS_PACKET *packet) 			}  			*tail = vp; 			while (*tail) tail = &vp->next; 			p += alen; 		} /* loop over array entries */ 	} /* loop over the entire packet */

Fixed version (after fix):
 int fr_dhcp_decode(RADIUS_PACKET *packet) 			}  			*tail = vp; 			while (*tail) tail = &(*tail)->next; 			p += alen; 		} /* loop over array entries */ 	} /* loop over the entire packet */

Patch:
patch: @@ -714,7 +714,7 @@ int fr_dhcp_decode(RADIUS_PACKET *packet)
 			}
 
 			*tail = vp;
-			while (*tail) tail = &vp->next;
+			while (*tail) tail = &(*tail)->next;
 			p += alen;
 		} /* loop over array entries */
 	} /* loop over the entire packet */
path: src/lib/dhcp.c
Vulnerability: Memory leak in the inotify_init1 function in fs/notify/inotify/inotify_user.c in the Linux kernel before 2.6.37 allows local users to cause a denial of service (memory consumption) via vectors involving failed attempts to create files.
Vulnerability ID: CVE-2010-4250
CWE: CWE-399
Severity score: 6.9
Project: https://github.com/torvalds/linux
Published: 2012-06-21
File: fs/notify/inotify/inotify_user.c
Commit message: inotify: stop kernel memory leak on file creation failure

If inotify_init is unable to allocate a new file for the new inotify
group we leak the new group.  This patch drops the reference on the
group on file allocation failure.

Reported-by: Vegard Nossum <vegard.nossum@gmail.com>
cc: stable@kernel.org
Signed-off-by: Eric Paris <eparis@redhat.com>
Commit author: Eric Paris

Vulnerable version (before fix):
 SYSCALL_DEFINE1(inotify_init1, int, flags) 	if (ret >= 0) 		return ret;  	atomic_dec(&user->inotify_devs); out_free_uid: 	free_uid(user);

Fixed version (after fix):
 SYSCALL_DEFINE1(inotify_init1, int, flags) 	if (ret >= 0) 		return ret;  	fsnotify_put_group(group); 	atomic_dec(&user->inotify_devs); out_free_uid: 	free_uid(user);

Patch:
patch: @@ -752,6 +752,7 @@ SYSCALL_DEFINE1(inotify_init1, int, flags)
 	if (ret >= 0)
 		return ret;
 
+	fsnotify_put_group(group);
 	atomic_dec(&user->inotify_devs);
 out_free_uid:
 	free_uid(user);
path: fs/notify/inotify/inotify_user.c
Vulnerability: Buffer overflow in the fuse_do_ioctl function in fs/fuse/file.c in the Linux kernel before 2.6.37 allows local users to cause a denial of service or possibly have unspecified other impact by leveraging the ability to operate a CUSE server.
Vulnerability ID: CVE-2010-4650
CWE: CWE-119
Severity score: 6.4
Project: https://github.com/torvalds/linux
Published: 2012-06-21
File: fs/fuse/file.c
Commit message: fuse: verify ioctl retries

Verify that the total length of the iovec returned in FUSE_IOCTL_RETRY
doesn't overflow iov_length().

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
CC: Tejun Heo <tj@kernel.org>
CC: <stable@kernel.org>         [2.6.31+]
Commit author: Miklos Szeredi

Vulnerable version (before fix):
 static int fuse_copy_ioctl_iovec(struct iovec *dst, void *src, 	return 0; }  /*  * For ioctls, there is no generic way to determine how much memory  * needs to be read and/or written.  Furthermore, ioctls are allowed long fuse_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg, 		in_iov = page_address(iov_page); 		out_iov = in_iov + in_iovs;  		goto retry; 	} 

Fixed version (after fix):
 static int fuse_copy_ioctl_iovec(struct iovec *dst, void *src, 	return 0; }  /* Make sure iov_length() won't overflow */ static int fuse_verify_ioctl_iov(struct iovec *iov, size_t count) { 	size_t n; 	u32 max = FUSE_MAX_PAGES_PER_REQ << PAGE_SHIFT;  	for (n = 0; n < count; n++) { 		if (iov->iov_len > (size_t) max) 			return -ENOMEM; 		max -= iov->iov_len; 	} 	return 0; }  /*  * For ioctls, there is no generic way to determine how much memory  * needs to be read and/or written.  Furthermore, ioctls are allowed long fuse_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg, 		in_iov = page_address(iov_page); 		out_iov = in_iov + in_iovs;  		err = fuse_verify_ioctl_iov(in_iov, in_iovs); 		if (err) 			goto out;  		err = fuse_verify_ioctl_iov(out_iov, out_iovs); 		if (err) 			goto out;  		goto retry; 	} 

Patch:
patch: @@ -1666,6 +1666,20 @@ static int fuse_copy_ioctl_iovec(struct iovec *dst, void *src,
 	return 0;
 }
 
+/* Make sure iov_length() won't overflow */
+static int fuse_verify_ioctl_iov(struct iovec *iov, size_t count)
+{
+	size_t n;
+	u32 max = FUSE_MAX_PAGES_PER_REQ << PAGE_SHIFT;
+
+	for (n = 0; n < count; n++) {
+		if (iov->iov_len > (size_t) max)
+			return -ENOMEM;
+		max -= iov->iov_len;
+	}
+	return 0;
+}
+
 /*
  * For ioctls, there is no generic way to determine how much memory
  * needs to be read and/or written.  Furthermore, ioctls are allowed
@@ -1858,6 +1872,14 @@ long fuse_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg,
 		in_iov = page_address(iov_page);
 		out_iov = in_iov + in_iovs;
 
+		err = fuse_verify_ioctl_iov(in_iov, in_iovs);
+		if (err)
+			goto out;
+
+		err = fuse_verify_ioctl_iov(out_iov, out_iovs);
+		if (err)
+			goto out;
+
 		goto retry;
 	}
path: fs/fuse/file.c
Vulnerability: chef-server-api/app/controllers/users.rb in the API in Chef before 0.9.0 does not require administrative privileges for the create, destroy, and update methods, which allows remote authenticated users to manage user accounts via requests to the /users URI.
Vulnerability ID: CVE-2010-5142
CWE: CWE-264
Severity score: 6.4
Project: https://github.com/opscode/chef
Published: 2012-08-08
File: chef-server-api/app/controllers/users.rb
Commit message: CHEF-1289 API does not check for admin rights for user management
Commit author: Ian Meyer

Vulnerable version (before fix):
 class Users < Application   provides :json    before :authenticate_every    # GET to /users   def index

Fixed version (after fix):
 class Users < Application   provides :json    before :authenticate_every   before :is_admin, :only => [ :create, :destroy, :update ]    # GET to /users   def index

Patch:
patch: @@ -22,6 +22,7 @@ class Users < Application
   provides :json
 
   before :authenticate_every
+  before :is_admin, :only => [ :create, :destroy, :update ]
 
   # GET to /users
   def index
path: chef-server-api/app/controllers/users.rb
Vulnerability: Race condition in arch/x86/kvm/x86.c in the Linux kernel before 2.6.38 allows L2 guest OS users to cause a denial of service (L1 guest OS crash) via a crafted instruction that triggers an L2 emulation failure report, a similar issue to CVE-2014-7842.
Vulnerability ID: CVE-2010-5313
CWE: CWE-362
Severity score: 6.9
Project: https://github.com/torvalds/linux
Published: 2014-11-30
File: arch/x86/kvm/x86.c
Commit message: KVM: X86: Don't report L2 emulation failures to user-space

This patch prevents that emulation failures which result
from emulating an instruction for an L2-Guest results in
being reported to userspace.
Without this patch a malicious L2-Guest would be able to
kill the L1 by triggering a race-condition between an vmexit
and the instruction emulator.
With this patch the L2 will most likely only kill itself in
this situation.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Commit author: Joerg Roedel

Vulnerable version (before fix):
 EXPORT_SYMBOL_GPL(kvm_inject_realmode_interrupt);  static int handle_emulation_failure(struct kvm_vcpu *vcpu) { 	++vcpu->stat.insn_emulation_fail; 	trace_kvm_emulate_insn_failed(vcpu); 	vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; 	vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION; 	vcpu->run->internal.ndata = 0; 	kvm_queue_exception(vcpu, UD_VECTOR); 	return EMULATE_FAIL; }  static bool reexecute_instruction(struct kvm_vcpu *vcpu, gva_t gva)

Fixed version (after fix):
 EXPORT_SYMBOL_GPL(kvm_inject_realmode_interrupt);  static int handle_emulation_failure(struct kvm_vcpu *vcpu) { 	int r = EMULATE_DONE;  	++vcpu->stat.insn_emulation_fail; 	trace_kvm_emulate_insn_failed(vcpu); 	if (!is_guest_mode(vcpu)) { 		vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; 		vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION; 		vcpu->run->internal.ndata = 0; 		r = EMULATE_FAIL; 	} 	kvm_queue_exception(vcpu, UD_VECTOR);  	return r; }  static bool reexecute_instruction(struct kvm_vcpu *vcpu, gva_t gva)

Patch:
patch: @@ -4314,13 +4314,19 @@ EXPORT_SYMBOL_GPL(kvm_inject_realmode_interrupt);
 
 static int handle_emulation_failure(struct kvm_vcpu *vcpu)
 {
+	int r = EMULATE_DONE;
+
 	++vcpu->stat.insn_emulation_fail;
 	trace_kvm_emulate_insn_failed(vcpu);
-	vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
-	vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION;
-	vcpu->run->internal.ndata = 0;
+	if (!is_guest_mode(vcpu)) {
+		vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+		vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION;
+		vcpu->run->internal.ndata = 0;
+		r = EMULATE_FAIL;
+	}
 	kvm_queue_exception(vcpu, UD_VECTOR);
-	return EMULATE_FAIL;
+
+	return r;
 }
 
 static bool reexecute_instruction(struct kvm_vcpu *vcpu, gva_t gva)
path: arch/x86/kvm/x86.c
Vulnerability: In the Linux kernel before 2.6.37, an out of bounds array access happened in drivers/net/mlx4/port.c. When searching for a free entry in either mlx4_register_vlan() or mlx4_register_mac(), and there is no free entry, the loop terminates without updating the local variable free thus causing out of array bounds access.
Vulnerability ID: CVE-2010-5332
CWE: CWE-119
Severity score: 6.4
Project: https://github.com/torvalds/linux
Published: 2019-07-27
File: drivers/net/mlx4/port.c
Commit message: mlx4_en: Fix out of bounds array access

When searching for a free entry in either mlx4_register_vlan() or
mlx4_register_mac(), and there is no free entry, the loop terminates without
updating the local variable free thus causing out of array bounds access. Fix
this by adding a proper check outside the loop.

Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit author: Eli Cohen

Vulnerable version (before fix):
 int mlx4_register_mac(struct mlx4_dev *dev, u8 port, u64 mac, int *index) 			goto out; 		} 	} 	mlx4_dbg(dev, "Free MAC index is %d\n", free);  	if (table->total == table->max) { int mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan, int *index) 		} 	}  	if (table->total == table->max) { 		/* No free vlan entries */ 		err = -ENOSPC;

Fixed version (after fix):
 int mlx4_register_mac(struct mlx4_dev *dev, u8 port, u64 mac, int *index) 			goto out; 		} 	}  	if (free < 0) { 		err = -ENOMEM; 		goto out; 	}  	mlx4_dbg(dev, "Free MAC index is %d\n", free);  	if (table->total == table->max) { int mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan, int *index) 		} 	}  	if (free < 0) { 		err = -ENOMEM; 		goto out; 	}  	if (table->total == table->max) { 		/* No free vlan entries */ 		err = -ENOSPC;

Patch:
patch: @@ -111,6 +111,12 @@ int mlx4_register_mac(struct mlx4_dev *dev, u8 port, u64 mac, int *index)
 			goto out;
 		}
 	}
+
+	if (free < 0) {
+		err = -ENOMEM;
+		goto out;
+	}
+
 	mlx4_dbg(dev, "Free MAC index is %d\n", free);
 
 	if (table->total == table->max) {
@@ -205,6 +211,11 @@ int mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan, int *index)
 		}
 	}
 
+	if (free < 0) {
+		err = -ENOMEM;
+		goto out;
+	}
+
 	if (table->total == table->max) {
 		/* No free vlan entries */
 		err = -ENOSPC;
path: drivers/net/mlx4/port.c