[Security Discussion] j'vai:
"..There's a function in the implementation called futex_requeue(), which "requeues waiters from uaddr1 to uaddr2". I'm not really sure what that means, but basically uaddr1 is the address of a source futex in user-mode memory, and uaddr2 is the address of a destination futex in user-mode memory. But, because it was assumed that they'd always be distinct, the code provisions a bunch of stuff expecting to have two objects to deal with, and in the end some of them are just left there doing nothing - they point to uninitialised structures or memory.

Basically, the trick is that if you get a futex and call futex_requeue() with your futex as both uaddr1 and uaddr2, the structure that describes the futex (in user-mode memory, which you can access) is left with "dangling pointers", i.e. pointers to memory that hasn't been allocated yet. By then looking at those pointers and allocating memory to the locations it describes, you can write your own stuff there. Once execution passes down to kernel-mode, you've essentially got a situation where kernel-mode code is using data that you control, but in a context where it expects the data to be trusted..."

aah, terminal - "man futex" .. the man pages -

http://man7.org/linux/man-pages/man2/futex.2.html

how it ties in with the mobile phones, it has to do with the network sockets within the android (linux) kernel..

even the nexus 5 is reported to be issued an security update in relaton to this - https://community.sprint.com/baw/thread/163896 & that's only labeled a *security patch*...

these socket views came up some years ago, in the gnome d.e. & was asked about, & they're all related to network timing sockets -

What is the “Waiting Channel” of a process?

~good link~

you could actually see them, then analyze them later with the netstat command, & see the process in action via **cat /proc/some_pid/stack** in a shell..

in the upper userspace, you can *feel* it on action on your phone;

especially on a nexus 5 on sprint -

it's single path at a time triband rf chip when it lulls to/from lte to 3g at times, some ppl complain they see a *telephone calls unavailable now* or something to that nature,

or wifi that won't catch when turned on

or an lte signal that simply won't latch, keeping them stuck on 3g..

underneath in that chipset, it's like a human mind processing a blank for a few trying to decide before acting,

** it's that dead moment**

right then, that this issue speaks of, like below from that gnome link in '10..

1.A task can be either a Process3 or a Thread2

2.A Thread is a sub-section of a Process. Many threads can run parallel

3.A process is a full-blown program, it consists of one or more threads, though a program can consist of multiple processes as well.

4.Remember, this is still a very high level view of things, it's not considering the implementation details

•

__skb_recv_datagram

Wait for some data on a locked network socket.

•

sk_wait_data

Wait for some data on a network socket.

•

do_exit

This is the last part of quitting a process. do_exit() calls the schedule() next, to schedule another process. When do_exit() is called, the process is a ZOMBIE.

•

do_wait

A process is added to the schedulers wait queue.

•

pipe_wait, unix_stream_data_wait

A Process is waiting for data from a subprocess. This happens, for example, when you run this sort of code:

ooh, the *top* command can expose the upper levels of those processes also!

you know when i can *see* it?

when i'm listening to music while riding the subway underground with my nexus 5;

as my signal changes between stops losing service, re-gaining it.. it effects the volume of the music, this morning, the train had to pause between stops in a tunnel, & my music player sounded kind of muffled but the music was, edible for my ears, that pause in the tunel, made the nexus 5 lose total signal, & BAM, that loss, of processing in the networking , gave me gain in volume with the music player!

it's related to one chip doing all the work...