In ptdump_check_wx(), we pass walk_pgd() a start address of 0 (rather
than VA_START) for the init_mm. This means that any reported W&X
addresses are offset by VA_START, which is clearly wrong and can make
them appear like userspace addresses.
Fix this by telling the ptdump code that we're walking init_mm starting
at VA_START. We don't need to update the addr_markers, since these are
still valid bounds regardless.
Cc: <email address hidden>
Fixes: 1404d6f13e47 ("arm64: dump: Add checking for writable and exectuable pages")
Signed-off-by: Mark Rutland <email address hidden>
Cc: Kees Cook <email address hidden>
Cc: Laura Abbott <email address hidden>
Reported-by: Timur Tabi <email address hidden>
Signed-off-by: Will Deacon <email address hidden>
(cherry picked from commit 1d08a044cf12aee37dfd54837558e3295287b343)
Signed-off-by: dann frazier <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
When longer interface names are used, the action names exposed in
/proc/interrupts and /proc/irq/* maybe truncated. For example, when
using the predictable name algorithm in systemd on a HiSilicon D05,
I see:
Signed-off-by: dann frazier <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit f4ea89110df237da6fbcaab76af431e85f07d904)
Signed-off-by: dann frazier <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
mm/madvise.c: fix madvise() infinite loop under special circumstances
CVE-2017-18208
MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation. The calling
convention is quite subtle there. madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.
It seems this has been broken since introduction. Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.
[<email address hidden>: rewrite changelog]
Link: http://<email address hidden>
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <email address hidden>
Signed-off-by: guoxuenan <email address hidden>
Acked-by: Michal Hocko <email address hidden>
Cc: Minchan Kim <email address hidden>
Cc: zhangyi (F) <email address hidden>
Cc: Miao Xie <email address hidden>
Cc: Mike Rapoport <email address hidden>
Cc: Shaohua Li <email address hidden>
Cc: Andrea Arcangeli <email address hidden>
Cc: Mel Gorman <email address hidden>
Cc: Kirill A. Shutemov <email address hidden>
Cc: David Rientjes <email address hidden>
Cc: Anshuman Khandual <email address hidden>
Cc: Rik van Riel <email address hidden>
Cc: Carsten Otte <email address hidden>
Cc: Dan Williams <email address hidden>
Cc: <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry picked from commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Colin King <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
3d2be2c...
by
Dan Carpenter <email address hidden>
staging: ncpfs: memory corruption in ncp_read_kernel()
CVE-2018-8822
If the server is malicious then *bytes_read could be larger than the
size of the "target" buffer. It would lead to memory corruption when we
do the memcpy().
Reported-by: Dr Silvio Cesare of InfoSect <Silvio Cesare <email address hidden>
Signed-off-by: Dan Carpenter <email address hidden>
Cc: stable <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(backported from commit 4c41aa24baa4ed338241d05494f2c595c885af8f)
Signed-off-by: Po-Hsu Lin <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Colin King <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
The bug can be easily triggered, if an extra delay (e.g. 10ms) is added
between the test of DMF_FREEING & DMF_DELETING and dm_get() in
dm_get_from_kobject().
To fix it, we need to ensure the test of DMF_FREEING & DMF_DELETING and
dm_get() are done in an atomic way, so _minor_lock is used.
The other callers of dm_get() have also been checked to be OK: some
callers invoke dm_get() under _minor_lock, some callers invoke it under
_hash_lock, and dm_start_request() invoke it after increasing
md->open_count.
Cc: <email address hidden>
Signed-off-by: Hou Tao <email address hidden>
Signed-off-by: Mike Snitzer <email address hidden>
(cherry picked from commit b9a41d21dceadf8104812626ef85dc56ee8a60ed)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Colin King <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
6f0dce0...
by
Kevin Cernekee <email address hidden>
netlink: Add netns check on taps
CVE-2017-17449
Currently, a nlmon link inside a child namespace can observe systemwide
netlink activity. Filter the traffic so that nlmon can only sniff
netlink messages from its own netns.
Test case:
vpnns -- bash -c "ip link add nlmon0 type nlmon; \ ip link set nlmon0 up; \ tcpdump -i nlmon0 -q -w /tmp/nlmon.pcap -U" &
sudo ip xfrm state add src 10.1.1.1 dst 10.1.1.2 proto esp \
spi 0x1 mode transport \
auth sha1 0x6162633132330000000000000000000000000000 \
enc aes 0x00000000000000000000000000000000
grep --binary abc123 /tmp/nlmon.pcap
Signed-off-by: Kevin Cernekee <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 93c647643b48f0131f02e45da3bd367d80443291)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Juerg Haefliger <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
748e9dc...
by
Oliver Neukum <email address hidden>
media: usbtv: prevent double free in error case
CVE-2017-17975
Quoting the original report:
It looks like there is a double-free vulnerability in Linux usbtv driver
on an error path of usbtv_probe function. When audio registration fails,
usbtv_video_free function ends up freeing usbtv data structure, which
gets freed the second time under usbtv_video_fail label.
usbtv_audio_fail:
usbtv_video_free(usbtv); =>
v4l2_device_put(&usbtv->v4l2_dev);
=> v4l2_device_put
=> kref_put
=> v4l2_device_release
=> usbtv_release (CALLBACK)
=> kfree(usbtv) (1st time)
usbtv_video_fail:
usb_set_intfdata(intf, NULL);
usb_put_dev(usbtv->udev);
kfree(usbtv); (2nd time)
So, as we have refcounting, use it
Reported-by: Yavuz, Tuba <email address hidden>
Signed-off-by: Oliver Neukum <email address hidden>
CC: <email address hidden>
Signed-off-by: Hans Verkuil <email address hidden>
Signed-off-by: Mauro Carvalho Chehab <email address hidden>
(cherry picked from commit 50e7044535537b2a54c7ab798cd34c7f6d900bd2)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Khaled Elmously <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
In case of eDP because the panel has a fixed mode, the link rate
and lane count at which it is trained corresponds to the link BW
required to support the native resolution of the panel. In case of
panles with lower resolutions where fewer lanes are hooked up internally,
that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
So it is pointless to fallback to lower link rate/lane count in case
of link training failure on eDP connector since the lower link BW
will not support the native resolution of the panel and we cannot
prune the preferred mode on the eDP connector.
In case of Link training failure on the eDP panel, something is wrong
in the HW internally and hence driver errors out with a loud
and clear DRM_ERROR message.
v2:
* Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
Cc: Clinton Taylor <email address hidden>
Cc: Jim Bride <email address hidden>
Cc: Jani Nikula <email address hidden>
Cc: Ville Syrjala <email address hidden>
Cc: Dave Airlie <email address hidden>
Cc: Daniel Vetter <email address hidden>
Signed-off-by: Manasi Navare <email address hidden>
Reviewed-by: Ville Syrjala <email address hidden>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103369
Signed-off-by: Imre Deak <email address hidden>
Link: https://patchwork.freedesktop.org<email address hidden>
(cherry picked from commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677)
Signed-off-by: Rodrigo Vivi <email address hidden>
(backported from commit a306343bcd7df89d9d45a601929e26866e7b7a81)
Signed-off-by: AceLan Kao <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
