Re: [Discuss-gnuradio] UDP Source Error (on windows)

[Abdil Burak BAŞLI]

Hi,

 

I think this fix will be affected at the next release. Is there a predetermined time for the next release. Or Is there any workaround to use UDP source without error at v3.7.9.2.

 

Best regards

Burak.

 

 

From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+address@hidden On Behalf Of address@hidden
Sent: Thursday, May 19, 2016 7:08 PM
To: Andy Walls <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] UDP Source Error (on windows)

 

Not sure how this would get leveraged by itself.

But there are likely lots of kernel calls that have parameters that are ignored in certain contexts.  I would be astonished if a general-purpose, long-lived, operating existed without that being the case from time to time.

 

 

 

On 2016-05-19 11:58, Andy Walls wrote:

On Thu, 2016-05-19 at 11:32 -0400, address@hidden wrote:

I'll comment that the Windows socket implementation isn't in
compliance with the spirit of the robustness principle.  But, whatevs.
Easy enough to just remove that option for the UDP case.

I think it's a bit of a security failing of Linux to allow injection of
4 unused bytes into the kernel space from user-space for every locally
opened UDP socket.  I'm not sure how I could exploit it (perhaps coding
a jump instruction to a no-op sled somewhere nearby?),  but I'm not that
creative.

Meh.

-Andy

Dikkat: Bu elektronik posta mesaji kisisel ve ozeldir. Eger size gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmektedir. Mesajdaki gorusler gondericiye ait olup HAVELSAN A.S. resmi gorusu olmak zorunda degildir. Attention: This e-mail message is private and privileged.If you are not the recipient for whom this e-mail message is intended, please notify the sender immediately and delete this e-mail message from your system.All sent and received e-mail messages go through a virus scan. Any opinions presented in this e-mail message are solely those of the author and do not necessarily represent HAVELSAN A.S.`s formal and authorized views.