On 4/13/20 3:15 PM, Waiman Long wrote:
As said by Linus:
A symmetric naming is only helpful if it implies symmetries in use.
Otherwise it's actively misleading.
In "kzalloc()", the z is meaningful and an important part of what the
caller wants.
In "kzfree()", the z is actively d
_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr
*)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
_address = {
.sll_ifindex = interface_index,
.sll_halen = ETH_ALEN,
.sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr
*)
in the bounds of the socket buffer.
Jason A. Donenfeld (4):
ozwpan: Use proper check to prevent heap overflow
ozwpan: Use unsigned ints to prevent heap overflow
ozwpan: divide-by-zero leading to panic
ozwpan: unchecked signed subtraction leads to DoS
drivers/staging/ozwpan/ozhcd.c |
if (sendto(sockfd, &connect_packet, sizeof(connect_packet), 0, (struct
sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
usleep(30);
if (sendto(sockfd, &pwn_pack
o(sockfd, &connect_packet, sizeof(connect_packet), 0, (struct
sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
usleep(30);
if (sendto(sockfd, &pwn_packet, sizeof(pwn_packet), 0
On May 15, 2015 4:10 PM, "David Laight" wrote:
> Why not just check the length. eg:
> unsigned int data_len = elt->length;
> if (data_len < sizeof(struct oz_get_desc_rsp) + 1)
> break;
Sure.
> >
o(sockfd, &connect_packet, sizeof(connect_packet), 0, (struct
sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
usleep(30);
if (sendto(sockfd, &pwn_packet, sizeof(pwn_packet), 0
_address = {
.sll_ifindex = interface_index,
.sll_halen = ETH_ALEN,
.sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr
*)
if (sendto(sockfd, &connect_packet, sizeof(connect_packet), 0, (struct
sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
usleep(30);
if (sendto(sockfd, &pwn_pack
_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr
*)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
rx function, adding checks to ensure all reads and casts are
within the bounds of the socket buffer.
Jason A. Donenfeld (4):
ozwpan: Use proper check to prevent heap overflow
ozwpan: Use unsigned ints to prevent heap overflow
ozwpan: divide-by-zero leading to panic
ozwpan: unchecked signed subt
On Tue, May 26, 2015 at 3:32 PM, Dan Carpenter wrote:
> On Tue, May 26, 2015 at 02:17:46PM +0200, Jason A. Donenfeld wrote:
>> + data_len = elt->length -
>> sizeof(struct oz_get_desc_rsp) + 1;
>
> This was in
On Tue, May 26, 2015 at 4:06 PM, Dan Carpenter wrote:
> You sure do like wrapping to a high value and testing the result for
> wrapping instead of validating before doing the subtraction...
I do indeed. It seems like asking "did it overflow?" is more
straight-forward and easier to read than tryin
On Tue, May 26, 2015 at 3:56 PM, Dan Carpenter wrote:
>> elt->length is a u8, so the upper bound is 255.
>
> Yes. I know that, but is 255 correct?
Eventually body->data is passed to oz_hcd_get_desc_cnf along with
data_len. In there, body->data (now called desc) is memcpy'd into a
URB transfer bu
On Thu, May 28, 2015 at 1:04 PM, Dan Carpenter wrote:
> It's really not simpler to understand though.
Greg - do you want me to resubmit a v3 for this, or does it not really
matter and we can address this in another series? Personally, I'm
erring on the side of wanting to get *something* merged so
o(sockfd, &connect_packet, sizeof(connect_packet), 0, (struct
sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
usleep(30);
if (sendto(sockfd, &pwn_packet, sizeof(pwn_pa
ction, adding checks to ensure all reads and casts are
within the bounds of the socket buffer.
Jason A. Donenfeld (4):
ozwpan: Use proper check to prevent heap overflow
ozwpan: Use unsigned ints to prevent heap overflow
ozwpan: divide-by-zero leading to panic
ozwpan: unchecked signed subt
_address = {
.sll_ifindex = interface_index,
.sll_halen = ETH_ALEN,
.sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr
*)
if (sendto(sockfd, &connect_packet, sizeof(connect_packet), 0, (struct
sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
usleep(30);
if (sendto(sockfd, &pwn_pack
_mac[0], dest_mac[1], dest_mac[2],
dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr
*)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
retu
On Fri, May 29, 2015 at 2:41 PM, Dan Carpenter wrote:
> Acked-by: Dan Carpenter
Acked for the rest of the set too?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Fri, May 29, 2015 at 2:36 PM, Frans Klaver wrote:
>
> I would say that it is because part of the expression has been placed
> inside parentheses:
>
> a - b + 1 == a - (b - 1)
>
> Guess it makes the decision logic slightly more readable.
Yes, exactly this. It's so that the bounding check co
ed, May 13, 2015 at 8:33 PM, Jason A. Donenfeld wrote:
> On a slightly related note, there are several other vulnerabilities in
> this driver that are worth looking into. When ozwpan receives a packet,
> it casts the packet into a variety of different structs, based on the
> va
On Tue, Jun 2, 2015 at 3:35 AM, Greg Kroah-Hartman
wrote:
> I don't know, but I'm a bit loath to delete the driver from the tree as
> then people will just continue to use the version with all of the bugs.
Yea, I understand that. Though, I'm pretty sure that most users of
ozwpan use old forks tie
intained driver from the tree. It simply didn't pass the "staging
test".
Regards,
Jason
On Tue, Jun 2, 2015 at 1:35 PM, Jason A. Donenfeld wrote:
> On Tue, Jun 2, 2015 at 3:35 AM, Greg Kroah-Hartman
> wrote:
>> I don't know, but I'm a bit loath to delete
On Mon, Aug 10, 2015 at 3:31 PM, Jason A. Donenfeld wrote:
> Meanwhile Dan
> Carpenter has posted a patch for a security vulnerability in ozwpan
> that hasn't been reviewed or merged.
Sorry, I see that you did in fact pick up this patch, so I retract
that statement.
Nonetheless,
Ozwpan is completely unmaintained and potentially a security problem. As
this is a staging driver, it should be removed, since it has been
abandoned. Marking it as orphaned is the first step here.
Signed-off-by: Jason A. Donenfeld
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1
On Tue, Jun 16, 2020 at 12:54 PM Joe Perches wrote:
>
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary memzero_
29 matches
Mail list logo
