Cm 14.1 #7
Open
Cm 14.1 #7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Lowi expects the timestamp of bss in units of 1/10 ms. In driver all bss related timestamp is in units of ms. Due to this when scan results are sent to lowi the scan age is high. To address this, send age in units of 1/10 ms. CRs-Fixed: 1075045 Change-Id: Id0a5794357a232105352c1b38d1ce404eabcc4fd
Release 3.0.11.63 Change-Id: I2c74b2f3e90dcbd7230e5878b032a5788af667d7 CRs-Fixed: 688141
Currently mutex mgmt_pkt_lock destroy is called after freeing the WDA context. In this change fix is to destroy the lock before freeing the context in order to avoid possible system crash Change-Id: Iab55d2e64f80b2d40e0e080c9c80fcf5e1713cd4 CRs-Fixed: 1076848
Release 3.0.11.64 Change-Id: Idc503c162c4c5b0036e4e2be655c11cfb2229cf4 CRs-Fixed: 688141
Dereference of 'roamSession' pointer before NULL check in csrScanningStateMsgProcessor(). Change-Id: If302bdbd70be3fc235158744aa1be2334f24edb2 CRs-Fixed: 1076882
Release 3.0.11.65 Change-Id: Icc3e05a8c842e36405677a2084a8ea3063934064 CRs-Fixed: 688141
qcacld-2.0 to prima propagation If SAP receive auth from an already connected STA, it post eWNI_SME_DISASSOC_IND msg to SME to delete the STA context and return. STA may try to send auth again as it didnt receive auth resp. Now many frames (probe req, auth etc) may get accumulated in PE message queue and unless PE queue is fully processed SME queue will not be processed and thus del sta will get delayed. This may again cause STA to send more auth req and every time MC thread process an auth req before the sta is deleted, eWNI_SME_DISASSOC_IND msg is posted in SME message queue. And if PE keeps on getting auth before the sta is deleted, SME queue will pile up leading to crash. To fix this do not trigger del sta if it is already in progress. Change-Id: Icff3778d35ef7ea646463fe49c4335e260e9e156 CRs-Fixed: 982329
qcacld-2.0 to prima propagation It's a fix for sns issue. Set DUT as sap, ref client sends assoc req to DUT and as part of this frame processing lim does ADD_STA and posts eWNI_SME_ASSOC_IND to sme layer. Before SME layer sends eWNI_SME_ASSOC_CNF, DUT receives auth frame which triggers deauth. In this case lim layer will delete ref client's related info, but wma layer doesn't get any notification. To fix this lim has to notify wma to do DEL_STA for that peer. Change-Id: Id4aae51aae3fb68e752d09793ad3bce17665fc2e CRs-Fixed: 979687
Add ini params to configure & reduce the consecutive BMISS threshold when gEnableModulatedDTIM/gMaxLIModulatedDTIM are big, so that to compensate the side effect of BH failure. Change-Id: Id68e4bf5110e021b3c59b69898732f66eb298f32 CRs-Fixed: 1072240
Release 3.0.11.66 Change-Id: Ib81f1c8d51f0718a831b0f4368f106468ea294f5 CRs-Fixed: 688141
The length of bss descriptor is calculated using offset of IE field but when lim tries to get the IE length it doesnt use the offset which results in incorrect IE length. To fix use offset to get the ie length from bss descriptor Change-Id: I7abbde83aea1e0a1cfcd7bdb1a184158f75f2455 CRs-Fixed: 1082001
OEM_DATA_RSP_SIZE is maximum data response length exchanged between driver and firmware. Currently OEM_DATA_RSP_SIZE is used always in copying data from SMD. But firmware may not send OEM_DATA_RSP_SIZE amount of data. This can result in reading from unauthorized location and thus can lead to crash. Fix this by getting appropriate length of oem data response and use that length in copying. Change-Id: I2011aca892e7702ad1991ec0a4c8f7be15d1dedf CRs-Fixed: 1081497
wlan_hdd_set_filter is not checking if SSR is in progress or not. fix this by protecting wlan_hdd_set_filter with SSR check Change-Id: I58eb632b9ed100dd73b27983035f6f459bb34852 CRs-Fixed: 1080754
qcacld2.0 to prima propagation WLAN host driver access the inet6_dev address list without acquiring the read lock, if the kernel network stack deletes the address while driver is accessing the list, it can lead to referencing already freed address by the driver. Hence, fix is to take the read lock before accessing the address list. Change-Id: I934e9f2039f3ab8540e439b9e8a87efced98807c CRs-Fixed: 1048897
From static analysis it is found that adapter is not being validated before being accessed.This can lead to null pointer exception during corner cases. Do NULL check for Adapter before accessing. Change-Id: I8abec02d3cf546c1e7790c3f7dfaff9ac373ff6d CRs-Fixed: 1082363
Scan should be aborted before sending join request since DUT needs to be at home channel during connection. Add changes to abort current scans before try to connect to AP. Change-Id: Ifa445a6e0898789ec6b57b446936565405c51328 CRs-Fixed: 1081496
SSID scan is done as part of join request, if scan aborted it should be informed to HDD otherwise HDD may have incorrect connection state. Add changes to inform scan status using callback handler. Change-Id: Ia2b064a78554a2c0260e0f87609b3e274698f7a4 CRs-Fixed: 1081496
Currently SSR got triggered if scan rejected by driver due to connection states. Add driver changes to generate bug report before SSR triggers if current session id, rejected reason matches with last rejected sesssion id, reason and time delta between current time and rejected timestamp is greater than 5 mins. Change-Id: Ic64a6fd443104b291b5b7f6cda3bfbe8273c671a CRs-Fixed: 1081489
Compilation error happening with WLAN_FEATURE_RMC disabled. Remove ifdef WLAN_FEATURE_RMC macro in wlan_hdd_main.h. CRs-Fixed: 1082451 Change-Id: I390c65ffc8fb534c801831f879053eb9664f0738
wifi-hal expects number of radios as part of radio stats. So send the number of radios supported as 1 in radio stats. Change-Id: I088ae47ed75d610ed8d1f6eaae30b569885254e9 CRs-Fixed: 1082999
Presently, thread stuck timer starts before initializing timer work queue(along with work queue spinlock and linked-list are initialized), which is scheduled on timer expire, leading to crash if timer expires before work queue is initialized. Also, as thread stuck timer callback won't be processed during driver loading, initializing thread stuck timer once done with driver loading. Change-Id: Ibb289f93481ae39585a6c2c56e8eefca267d6330 CRs-Fixed: 1086969
Presently, thread stuck timer callback is called only if userdata is valid, from WD timer worker thread. But while initializing timer, userdata is set to NULL. Hence timer callback isn't called. Don't validate userdata in WD timer worker thread, before calling thread stuck timer expire. Change-Id: I1bca1d931e42941deab7c5fdbaee88fa2ec75f35 CRs-Fixed: 1087146
Due to improper sequencing, data sent to firmware gets corrupted, fix this issue with proper sequencing of the commands. Change-Id: I71d2b304a4b8df863c61d884ba907bd37a5e41b8 CRs-Fixed: 1093499
In csr_ssid_scan_done_callback(), Return failure status if scan_context is NULL to avoid dereferencing NULL pointer. Change-Id: Ic679e99cef9869aa5349b1b1892b8ed065286e62 CRs-Fixed: 1092464
Presently, LIM de-initialization is happening during FTM unload though LIM is not initialized during FTM load. In FTM mode, during driver unload don't de-initialize LIM module. Change-Id: Icd2ce2681587f92e5d8311f2f69c79dc4127be9a CRs-Fixed: 1094268
In function __hdd_softap_hard_start_xmit, station id is not validated with max station count, this might lead to a buffer overflow situation for array aStaInfo in SapCtx. Validate station id with max sta count. CRs-Fixed: 1093122 Change-Id: If9f59c5a7b76845bb7783a96453e595b5afa4f30
In function parse_Bufferforpkt, pkt data index is not validated. This may lead to a buffer overflow if the incoming buffer is too large. Validate packet buffer length with the total allowed pkt buffer size. Change-Id: I9b9ffa592cbe3a0d87af3cbbef3608bc59e01cfc CRs-Fixed: 1092599
While processing netlink packet(logger app), packet length is validated incorrectly, leading packets to drop without processing. Validate netlink packet lenght properly, by checking whole (including header) netlink packet size with skb's len. Change-Id: Ia6fc1a4c090084ad197ae198404c9083d0acb8e4 CRs-Fixed: 1075397
In function hdd_hostapd_select_queue, station id is not validated with max station count, this might lead to a buffer overflow situation for array aStaInfo in SapCtx. Validate station id with max sta count. Change-Id: Ic1dd825b6437e4b0d7d8ed133184674bbfa53699 CRs-Fixed: 1092611
As part of SETDFSSCANMODE cmd all the DFS channels are reset to passive channels in WNI_CFG_SCAN_CONTROL_LIST, but the timestamp of the last received beacon on these passive channels is not reset. Thus even if beacon is received on these channels the passive to active conversion does not happen as the timestamp is non 0. To fix this reset the timestamp of the last received beacon on the passive channels whenever the WNI_CFG_SCAN_CONTROL_LIST is reset. Change-Id: I83887cc43c38d5b045415278459c7be455085e34 CRs-Fixed: 1095474
HLOS Crypto driver needs to set CLR_CNTXT bit for operations with legacy software key registers. Change-Id: Iff482f726d106e99a4006f7077a171da3c7ca9c3 Signed-off-by: Zhen Kong <[email protected]> Signed-off-by: AnilKumar Chimata <[email protected]>
i2c_freq_mode in msm_cci_set_clk_param is populated from userspace. Validate to make sure it has valid values. If a large number is sent from userspace to avoid a buffer over write. CRs-Fixed: 1086833 Change-Id: I237f60dca3e3dbad4e6188bf047cf7ec5163d159 Signed-off-by: Rajesh Bondugula <[email protected]> Signed-off-by: VijayaKumar T M <[email protected]>
Validate the power setting size before copying. If userspace sends a value which is greater than MAX_POWER_CONFIG, then the driver accesses unintended memory. This change will fix the issue. CRs-Fixed: 1093232 Signed-off-by: Rajesh Bondugula <[email protected]> Change-Id: Ia49963248a94765baa19695294b197ea6f3bb8e2
To prevent potential kernel stack data leakage, initialize channel_map[]. CRs-Fixed: 1100878 Change-Id: I7b81cea20485bc7514551672bb54c7fd455049e3 Signed-off-by: Xiaojun Sang <[email protected]>
Hardcoding the third argument in strnstr function is resulting in out of bounds access. Set the third argument to sizeof the character string passed as the first argument to prevent out of bounds access. CRs-Fixed: 832915 Change-Id: I61be88701340e271fd866e0e1801722dbe7d63ac Signed-off-by: Aravind Kumar <[email protected]>
The size of the BCL attribute is incorrect due to a precedence bug: This was observed while booting with Kernel Address Sanitizer(KASan) enabled. ============================================================================= BUG kmalloc-64 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Slab 0xffffffbc0661c6e0 objects=64 used=64 fp=0x (null) flags=0x0080 INFO: Object 0xffffffc0a360bb00 @offset=2816 fp=0xffffffc0a3454728 Bytes b4 ffffffc0a360baf0: 3f 37 9c 1c 00 00 00 00 02 00 02 00 a9 4e ad de ?7...........N.. Object ffffffc0a360bb00: 28 47 45 a3 c0 ff ff ff 48 47 45 a3 c0 ff ff ff (GE.....HGE..... Object ffffffc0a360bb10: 68 47 45 a3 c0 ff ff ff 00 00 00 00 00 00 00 00 hGE............. Object ffffffc0a360bb20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffffffc0a360bb30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B 3.10.49-g465b172-00133-gb931dc1 #134 Call trace: [<ffffffc00040a2a4>] dump_backtrace+0x0/0x1d4 [<ffffffc00040a488>] show_stack+0x10/0x1c [<ffffffc000f971a4>] dump_stack+0x1c/0x28 [<ffffffc00054aeb4>] print_trailer+0x144/0x158 [<ffffffc00054b210>] object_err+0x38/0x4c [<ffffffc00054fed8>] kasan_report_error+0x210/0x3b0 [<ffffffc000550188>] kasan_report+0x68/0x78 [<ffffffc00054f1b0>] __asan_load8+0x90/0x9c [<ffffffc0005dff78>] internal_create_group+0x1a0/0x2f4 [<ffffffc0005e00dc>] sysfs_create_group+0x10/0x1c [<ffffffc000c5eb9c>] msm_bcl_register_param+0x384/0x450 [<ffffffc000c61758>] bcl_probe+0x840/0xb84 [<ffffffc000a394b8>] spmi_drv_probe+0x2c/0x3c [<ffffffc000999150>] driver_probe_device+0x1f4/0x47c [<ffffffc0009994c4>] __driver_attach+0x88/0xc0 [<ffffffc000996434>] bus_for_each_dev+0xdc/0x11c [<ffffffc0009988ac>] driver_attach+0x2c/0x3c [<ffffffc0009981fc>] bus_add_driver+0x1bc/0x32c [<ffffffc000999d1c>] driver_register+0x10c/0x1d8 [<ffffffc000a39a30>] spmi_driver_register+0x98/0xa8 [<ffffffc00183a300>] bcl_perph_init+0x2c/0x38 [<ffffffc000400b00>] do_one_initcall+0xcc/0x188 [<ffffffc001800b54>] kernel_init_freeable+0x1c0/0x264 [<ffffffc000f89b84>] kernel_init+0x10/0xcc Memory state around the buggy address: ffffffc0a360ba00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0a360ba80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0a360bb00: 00 00 00 01 fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffffc0a360bb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffffc0a360bc00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by adding parantheses to fix precedence. CRs-Fixed: 826589 Change-Id: Ia58b6e52c491b89b10a2b8fe45445372bfe9fa20 Signed-off-by: David Keitel <[email protected]>
Some of the ioctl command handling is not properly using the copy_from_user interface. Fix these issues and cleanup the ioctl functions to make sure there is no illegal memory access. Bug: 35399801 CRs-Fixed: 1090482 Change-Id: Ib18e4b132d3487a3103335768aad5df2ebe13f2d Signed-off-by: Walter Yang <[email protected]> Signed-off-by: Siqi Lin <[email protected]> (am from https://source.codeaurora.org/quic/la//kernel/msm-3.10/commit/?id=07e4006db8b3bf4ada64ec7c87f27df38ea77a81)
The trace_printk() code will allocate extra buffers if the compile detects that a trace_printk() is used. To do this, the format of the trace_printk() is saved to the __trace_printk_fmt section, and if that section is bigger than zero, the buffers are allocated (along with a message that this has happened). If trace_printk() uses a format that is not a constant, and thus something not guaranteed to be around when the print happens, the compiler optimizes the fmt out, as it is not used, and the __trace_printk_fmt section is not filled. This means the kernel will not allocate the special buffers needed for the trace_printk() and the trace_printk() will not write anything to the tracing buffer. Adding a "__used" to the variable in the __trace_printk_fmt section will keep it around, even though it is set to NULL. This will keep the string from being printed in the debugfs/tracing/printk_formats section as it is not needed. Reported-by: Vlastimil Babka <[email protected]> Fixes: 07d777f "tracing: Add percpu buffers for trace_printk()" Cc: [email protected] # v3.5+ Bug: 34277115 Signed-off-by: Steven Rostedt <[email protected]> Change-Id: I10ce56caa41c7644d9d290d9ed272a6d156c938c
This likely breaks tracing tools like trace-cmd. It logs in the same format but now addresses are all 0x0. Bug: 34277115 Change-Id: Ifb0d4d2a184bf0d95726de05b1acee0287a375d9
If userspace closes the fd after an error on copying to userspace, the fences may be freed incorrectly. Make sure fences are installed after all checks pass. Bug: 32402303 Change-Id: Ieb50296c87e09549db2734bd70bb6ee8d311ad40 CRs-Fixed: 2000664 Signed-off-by: Naseer Ahmed <[email protected]> Signed-off-by: Steve Pfetsch <[email protected]>
Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to wrapping issues. To ensure we are correctly ensuring that the two ESN structures are the same size compare both the overall size as reported by xfrm_replay_state_esn_len() and the internal length are the same. CVE-2017-7184 Signed-off-by: Andy Whitcroft <[email protected]> Acked-by: Steffen Klassert <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Change-Id: Ieca2af8ac5cc721117a11baa501c3a5fc14ab4b0
Serialize core_info_read with lock so that multiple concurrent threads do not cause the write to overflow. Also have the bound check to avoid overflow in write_str function. CRs-Fixed: 2013361 Change-Id: Ia18a4b94cafd69af1d367861f2499fc202f18e9f Signed-off-by: Abdulla Anam <[email protected]> Signed-off-by: Sanjay Singh <[email protected]>
Add size check to ensure the payload fits inside the declared payload size to prevent loss of data when copying. CRs-Fixed: 2009224 Signed-off-by: Siena Richard <[email protected]> Change-Id: I4275c626605272941143b54a7b8861b25f8e750a
Pointer after kfree is not sanitized. Set pointer to NULL. CRs-Fixed: 2008031 Change-Id: Ia59a57fcd142a6ed18d168992b8da4019314afa4 Signed-off-by: Xiaojun Sang <[email protected]> Signed-off-by: Bikshapathi Kothapeta <[email protected]>
commit 42cb14b110a5698ccf26ce59c4441722605a3743 upstream. clear_page_dirty_for_io() has accumulated writeback and memcg subtleties since v2.6.16 first introduced page migration; and the set_page_dirty() which completed its migration of PageDirty, later had to be moderated to __set_page_dirty_nobuffers(); then PageSwapBacked had to skip that too. No actual problems seen with this procedure recently, but if you look into what the clear_page_dirty_for_io(page)+set_page_dirty(newpage) is actually achieving, it turns out to be nothing more than moving the PageDirty flag, and its NR_FILE_DIRTY stat from one zone to another. It would be good to avoid a pile of irrelevant decrementations and incrementations, and improper event counting, and unnecessary descent of the radix_tree under tree_lock (to set the PAGECACHE_TAG_DIRTY which radix_tree_replace_slot() left in place anyway). Do the NR_FILE_DIRTY movement, like the other stats movements, while interrupts still disabled in migrate_page_move_mapping(); and don't even bother if the zone is the same. Do the PageDirty movement there under tree_lock too, where old page is frozen and newpage not yet visible: bearing in mind that as soon as newpage becomes visible in radix_tree, an un-page-locked set_page_dirty() might interfere (or perhaps that's just not possible: anything doing so should already hold an additional reference to the old page, preventing its migration; but play safe). But we do still need to transfer PageDirty in migrate_page_copy(), for those who don't go the mapping route through migrate_page_move_mapping(). CVE-2016-3070 Signed-off-by: Hugh Dickins <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: KOSAKI Motohiro <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> [[email protected]: backported to 3.10: adjusted context] Signed-off-by: Charles (Chas) Williams <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Change-Id: I95d3cb66fe662ff9c169f51571ebeeda6c2d66c5
…yrings commit ee8f844e3c5a73b999edf733df1c529d6503ec2f upstream. This fixes CVE-2016-9604. Keyrings whose name begin with a '.' are special internal keyrings and so userspace isn't allowed to create keyrings by this name to prevent shadowing. However, the patch that added the guard didn't fix KEYCTL_JOIN_SESSION_KEYRING. Not only can that create dot-named keyrings, it can also subscribe to them as a session keyring if they grant SEARCH permission to the user. This, for example, allows a root process to set .builtin_trusted_keys as its session keyring, at which point it has full access because now the possessor permissions are added. This permits root to add extra public keys, thereby bypassing module verification. This also affects kexec and IMA. This can be tested by (as root): keyctl session .builtin_trusted_keys keyctl add user a a @s keyctl list @s which on my test box gives me: 2 keys in keyring: 180010936: ---lswrv 0 0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05 801382539: --alswrv 0 0 user: a Fix this by rejecting names beginning with a '.' in the keyctl. Change-Id: I3e2d9907d61eba3b39b97415dc344f8186ebc817 Signed-off-by: David Howells <[email protected]> Acked-by: Mimi Zohar <[email protected]> cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit c9f838d104fed6f2f61d68164712e3204bf5271b upstream. This fixes CVE-2017-7472. Running the following program as an unprivileged user exhausts kernel memory by leaking thread keyrings: #include <keyutils.h> int main() { for (;;) keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING); } Fix it by only creating a new thread keyring if there wasn't one before. To make things more consistent, make install_thread_keyring_to_cred() and install_process_keyring_to_cred() both return 0 if the corresponding keyring is already present. Change-Id: I1355f6043290f23132d123c37c2c0fb3b5a7f671 Fixes: d84f4f9 ("CRED: Inaugurate COW credentials") Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit c1644fe041ebaf6519f6809146a77c3ead9193af upstream. This fixes CVE-2017-6951. Userspace should not be able to do things with the "dead" key type as it doesn't have some of the helper functions set upon it that the kernel needs. Attempting to use it may cause the kernel to crash. Fix this by changing the name of the type to ".dead" so that it's rejected up front on userspace syscalls by key_get_type_from_user(). Though this doesn't seem to affect recent kernels, it does affect older ones, certainly those prior to: commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81 Author: David Howells <[email protected]> Date: Tue Sep 16 17:36:06 2014 +0100 KEYS: Remove key_type::match in favour of overriding default by match_preparse which went in before 3.18-rc1. Change-Id: I724617d072ec6e84e23b3bf93b55f8d2b3ad792a Signed-off-by: David Howells <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
With the optimizations around not clearing the full request at alloc time, we are leaving some of the needed init for REQ_TYPE_BLOCK_PC up to the user allocating the request. Add a blk_rq_set_block_pc() that sets the command type to REQ_TYPE_BLOCK_PC, and properly initializes the members associated with this type of request. Update callers to use this function instead of manipulating rq->cmd_type directly. Includes fixes from Christoph Hellwig <[email protected]> for my half-assed attempt. Change-Id: Ifc386dfb951c5d6adebf48ff38135dda28e4b1ce Signed-off-by: Jens Axboe <[email protected]>
- remove the 16 byte CDB (SCSI command) length limit from the sg driver by handling longer CDBs the same way as the bsg driver. Remove comment from sg.h public interface about the cmd_len field being limited to 16 bytes. - remove some dead code caused by this change - cleanup comment block at the top of sg.h, fix urls Change-Id: Ie8150e5375b3316d5d5206f079c4a50f1c50b755 Signed-off-by: Douglas Gilbert <[email protected]> Reviewed-by: Mike Christie <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
The user can control the size of the next command passed along, but the value passed to the ioctl isn't checked against the usable max command size. Change-Id: I9e8eb8ca058c0103a22f5d99d77919432893aa4c Cc: <[email protected]> Signed-off-by: Peter Chang <[email protected]> Acked-by: Douglas Gilbert <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
Alberto97
pushed a commit
to moto8916/android_kernel_motorola_msm8916
that referenced
this pull request
Nov 4, 2017
[ Upstream commit 6900317f5eff0a7070c5936e5383f589e0de7a09 ]
David and HacKurx reported a following/similar size overflow triggered
in a grsecurity kernel, thanks to PaX's gcc size overflow plugin:
(Already fixed in later grsecurity versions by Brad and PaX Team.)
[ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314
cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr;
[ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ CyanogenMod#7
[ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...]
[ 1002.296153] ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8
[ 1002.296162] ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8
[ 1002.296169] ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60
[ 1002.296176] Call Trace:
[ 1002.296190] [<ffffffff818129ba>] dump_stack+0x45/0x57
[ 1002.296200] [<ffffffff8121f838>] report_size_overflow+0x38/0x60
[ 1002.296209] [<ffffffff816a979e>] scm_detach_fds+0x2ce/0x300
[ 1002.296220] [<ffffffff81791899>] unix_stream_read_generic+0x609/0x930
[ 1002.296228] [<ffffffff81791c9f>] unix_stream_recvmsg+0x4f/0x60
[ 1002.296236] [<ffffffff8178dc00>] ? unix_set_peek_off+0x50/0x50
[ 1002.296243] [<ffffffff8168fac7>] sock_recvmsg+0x47/0x60
[ 1002.296248] [<ffffffff81691522>] ___sys_recvmsg+0xe2/0x1e0
[ 1002.296257] [<ffffffff81693496>] __sys_recvmsg+0x46/0x80
[ 1002.296263] [<ffffffff816934fc>] SyS_recvmsg+0x2c/0x40
[ 1002.296271] [<ffffffff8181a3ab>] entry_SYSCALL_64_fastpath+0x12/0x85
Further investigation showed that this can happen when an *odd* number of
fds are being passed over AF_UNIX sockets.
In these cases CMSG_LEN(i * sizeof(int)) and CMSG_SPACE(i * sizeof(int)),
where i is the number of successfully passed fds, differ by 4 bytes due
to the extra CMSG_ALIGN() padding in CMSG_SPACE() to an 8 byte boundary
on 64 bit. The padding is used to align subsequent cmsg headers in the
control buffer.
When the control buffer passed in from the receiver side *lacks* these 4
bytes (e.g. due to buggy/wrong API usage), then msg->msg_controllen will
overflow in scm_detach_fds():
int cmlen = CMSG_LEN(i * sizeof(int)); <--- cmlen w/o tail-padding
err = put_user(SOL_SOCKET, &cm->cmsg_level);
if (!err)
err = put_user(SCM_RIGHTS, &cm->cmsg_type);
if (!err)
err = put_user(cmlen, &cm->cmsg_len);
if (!err) {
cmlen = CMSG_SPACE(i * sizeof(int)); <--- cmlen w/ 4 byte extra tail-padding
msg->msg_control += cmlen;
msg->msg_controllen -= cmlen; <--- iff no tail-padding space here ...
} ... wrap-around
F.e. it will wrap to a length of 18446744073709551612 bytes in case the
receiver passed in msg->msg_controllen of 20 bytes, and the sender
properly transferred 1 fd to the receiver, so that its CMSG_LEN results
in 20 bytes and CMSG_SPACE in 24 bytes.
In case of MSG_CMSG_COMPAT (scm_detach_fds_compat()), I haven't seen an
issue in my tests as alignment seems always on 4 byte boundary. Same
should be in case of native 32 bit, where we end up with 4 byte boundaries
as well.
In practice, passing msg->msg_controllen of 20 to recvmsg() while receiving
a single fd would mean that on successful return, msg->msg_controllen is
being set by the kernel to 24 bytes instead, thus more than the input
buffer advertised. It could f.e. become an issue if such application later
on zeroes or copies the control buffer based on the returned msg->msg_controllen
elsewhere.
Maximum number of fds we can send is a hard upper limit SCM_MAX_FD (253).
Going over the code, it seems like msg->msg_controllen is not being read
after scm_detach_fds() in scm_recv() anymore by the kernel, good!
Relevant recvmsg() handler are unix_dgram_recvmsg() (unix_seqpacket_recvmsg())
and unix_stream_recvmsg(). Both return back to their recvmsg() caller,
and ___sys_recvmsg() places the updated length, that is, new msg_control -
old msg_control pointer into msg->msg_controllen (hence the 24 bytes seen
in the example).
Long time ago, Wei Yongjun fixed something related in commit 1ac70e7
("[NET]: Fix function put_cmsg() which may cause usr application memory
overflow").
RFC3542, section 20.2. says:
The fields shown as "XX" are possible padding, between the cmsghdr
structure and the data, and between the data and the next cmsghdr
structure, if required by the implementation. While sending an
application may or may not include padding at the end of last
ancillary data in msg_controllen and implementations must accept both
as valid. On receiving a portable application must provide space for
padding at the end of the last ancillary data as implementations may
copy out the padding at the end of the control message buffer and
include it in the received msg_controllen. When recvmsg() is called
if msg_controllen is too small for all the ancillary data items
including any trailing padding after the last item an implementation
may set MSG_CTRUNC.
Since we didn't place MSG_CTRUNC for already quite a long time, just do
the same as in 1ac70e7 to avoid an overflow.
Btw, even man-page author got this wrong :/ See db939c9b26e9 ("cmsg.3: Fix
error in SCM_RIGHTS code sample"). Some people must have copied this (?),
thus it got triggered in the wild (reported several times during boot by
David and HacKurx).
No Fixes tag this time as pre 2002 (that is, pre history tree).
Reported-by: David Sterba <[email protected]>
Reported-by: HacKurx <[email protected]>
Cc: PaX Team <[email protected]>
Cc: Emese Revfy <[email protected]>
Cc: Brad Spengler <[email protected]>
Cc: Wei Yongjun <[email protected]>
Cc: Eric Dumazet <[email protected]>
Reviewed-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Ahmed-Hady
pushed a commit
to Ahmed-Hady/android_kernel_motorola_msm8916
that referenced
this pull request
Mar 9, 2018
commit d3051b489aa81ca9ba62af366149ef42b8dae97c upstream. A panic was seen in the following sitation. There are two threads running on the system. The first thread is a system monitoring thread that is reading /proc/modules. The second thread is loading and unloading a module (in this example I'm using my simple dummy-module.ko). Note, in the "real world" this occurred with the qlogic driver module. When doing this, the following panic occurred: ------------[ cut here ]------------ kernel BUG at kernel/module.c:3739! invalid opcode: 0000 [#1] SMP Modules linked in: binfmt_misc sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw igb gf128mul glue_helper iTCO_wdt iTCO_vendor_support ablk_helper ptp sb_edac cryptd pps_core edac_core shpchp i2c_i801 pcspkr wmi lpc_ich ioatdma mfd_core dca ipmi_si nfsd ipmi_msghandler auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm isci drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: dummy_module] CPU: 37 PID: 186343 Comm: cat Tainted: GF O-------------- 3.10.0+ CyanogenMod#7 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013 task: ffff8807fd2d8000 ti: ffff88080fa7c000 task.ti: ffff88080fa7c000 RIP: 0010:[<ffffffff810d64c5>] [<ffffffff810d64c5>] module_flags+0xb5/0xc0 RSP: 0018:ffff88080fa7fe18 EFLAGS: 00010246 RAX: 0000000000000003 RBX: ffffffffa03b5200 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffff88080fa7fe38 RDI: ffffffffa03b5000 RBP: ffff88080fa7fe28 R08: 0000000000000010 R09: 0000000000000000 R10: 0000000000000000 R11: 000000000000000f R12: ffffffffa03b5000 R13: ffffffffa03b5008 R14: ffffffffa03b5200 R15: ffffffffa03b5000 FS: 00007f6ae57ef740(0000) GS:ffff88101e7a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000404f70 CR3: 0000000ffed48000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffffffffa03b5200 ffff8810101e4800 ffff88080fa7fe70 ffffffff810d666c ffff88081e807300 000000002e0f2fbf 0000000000000000 ffff88100f257b00 ffffffffa03b5008 ffff88080fa7ff48 ffff8810101e4800 ffff88080fa7fee0 Call Trace: [<ffffffff810d666c>] m_show+0x19c/0x1e0 [<ffffffff811e4d7e>] seq_read+0x16e/0x3b0 [<ffffffff812281ed>] proc_reg_read+0x3d/0x80 [<ffffffff811c0f2c>] vfs_read+0x9c/0x170 [<ffffffff811c1a58>] SyS_read+0x58/0xb0 [<ffffffff81605829>] system_call_fastpath+0x16/0x1b Code: 48 63 c2 83 c2 01 c6 04 03 29 48 63 d2 eb d9 0f 1f 80 00 00 00 00 48 63 d2 c6 04 13 2d 41 8b 0c 24 8d 50 02 83 f9 01 75 b2 eb cb <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 RIP [<ffffffff810d64c5>] module_flags+0xb5/0xc0 RSP <ffff88080fa7fe18> Consider the two processes running on the system. CPU 0 (/proc/modules reader) CPU 1 (loading/unloading module) CPU 0 opens /proc/modules, and starts displaying data for each module by traversing the modules list via fs/seq_file.c:seq_open() and fs/seq_file.c:seq_read(). For each module in the modules list, seq_read does op->start() <-- this is a pointer to m_start() op->show() <- this is a pointer to m_show() op->stop() <-- this is a pointer to m_stop() The m_start(), m_show(), and m_stop() module functions are defined in kernel/module.c. The m_start() and m_stop() functions acquire and release the module_mutex respectively. ie) When reading /proc/modules, the module_mutex is acquired and released for each module. m_show() is called with the module_mutex held. It accesses the module struct data and attempts to write out module data. It is in this code path that the above BUG_ON() warning is encountered, specifically m_show() calls static char *module_flags(struct module *mod, char *buf) { int bx = 0; BUG_ON(mod->state == MODULE_STATE_UNFORMED); ... The other thread, CPU 1, in unloading the module calls the syscall delete_module() defined in kernel/module.c. The module_mutex is acquired for a short time, and then released. free_module() is called without the module_mutex. free_module() then sets mod->state = MODULE_STATE_UNFORMED, also without the module_mutex. Some additional code is called and then the module_mutex is reacquired to remove the module from the modules list: /* Now we can delete it from the lists */ mutex_lock(&module_mutex); stop_machine(__unlink_module, mod, NULL); mutex_unlock(&module_mutex); This is the sequence of events that leads to the panic. CPU 1 is removing dummy_module via delete_module(). It acquires the module_mutex, and then releases it. CPU 1 has NOT set dummy_module->state to MODULE_STATE_UNFORMED yet. CPU 0, which is reading the /proc/modules, acquires the module_mutex and acquires a pointer to the dummy_module which is still in the modules list. CPU 0 calls m_show for dummy_module. The check in m_show() for MODULE_STATE_UNFORMED passed for dummy_module even though it is being torn down. Meanwhile CPU 1, which has been continuing to remove dummy_module without holding the module_mutex, now calls free_module() and sets dummy_module->state to MODULE_STATE_UNFORMED. CPU 0 now calls module_flags() with dummy_module and ... static char *module_flags(struct module *mod, char *buf) { int bx = 0; BUG_ON(mod->state == MODULE_STATE_UNFORMED); and BOOM. Acquire and release the module_mutex lock around the setting of MODULE_STATE_UNFORMED in the teardown path, which should resolve the problem. Testing: In the unpatched kernel I can panic the system within 1 minute by doing while (true) do insmod dummy_module.ko; rmmod dummy_module.ko; done and while (true) do cat /proc/modules; done in separate terminals. In the patched kernel I was able to run just over one hour without seeing any issues. I also verified the output of panic via sysrq-c and the output of /proc/modules looks correct for all three states for the dummy_module. dummy_module 12661 0 - Unloading 0xffffffffa03a5000 (OE-) dummy_module 12661 0 - Live 0xffffffffa03bb000 (OE) dummy_module 14015 1 - Loading 0xffffffffa03a5000 (OE+) Signed-off-by: Prarit Bhargava <[email protected]> Reviewed-by: Oleg Nesterov <[email protected]> Signed-off-by: Rusty Russell <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Ahmed-Hady
pushed a commit
to Ahmed-Hady/android_kernel_motorola_msm8916
that referenced
this pull request
Aug 15, 2018
commit 420902c9d086848a7548c83e0a49021514bd71b7 upstream.
If we hold the superblock lock while calling reiserfs_quota_on_mount(), we can
deadlock our own worker - mount blocks kworker/3:2, sleeps forever more.
crash> ps|grep UN
715 2 3 ffff880220734d30 UN 0.0 0 0 [kworker/3:2]
9369 9341 2 ffff88021ffb7560 UN 1.3 493404 123184 Xorg
9665 9664 3 ffff880225b92ab0 UN 0.0 47368 812 udisks-daemon
10635 10403 3 ffff880222f22c70 UN 0.0 14904 936 mount
crash> bt ffff880220734d30
PID: 715 TASK: ffff880220734d30 CPU: 3 COMMAND: "kworker/3:2"
#0 [ffff8802244c3c20] schedule at ffffffff8144584b
#1 [ffff8802244c3cc8] __rt_mutex_slowlock at ffffffff814472b3
#2 [ffff8802244c3d28] rt_mutex_slowlock at ffffffff814473f5
#3 [ffff8802244c3dc8] reiserfs_write_lock at ffffffffa05f28fd [reiserfs]
CyanogenMod#4 [ffff8802244c3de8] flush_async_commits at ffffffffa05ec91d [reiserfs]
CyanogenMod#5 [ffff8802244c3e08] process_one_work at ffffffff81073726
CyanogenMod#6 [ffff8802244c3e68] worker_thread at ffffffff81073eba
CyanogenMod#7 [ffff8802244c3ec8] kthread at ffffffff810782e0
#8 [ffff8802244c3f48] kernel_thread_helper at ffffffff81450064
crash> rd ffff8802244c3cc8 10
ffff8802244c3cc8: ffffffff814472b3 ffff880222f23250 .rD.....P2."....
ffff8802244c3cd8: 0000000000000000 0000000000000286 ................
ffff8802244c3ce8: ffff8802244c3d30 ffff880220734d80 0=L$.....Ms ....
ffff8802244c3cf8: ffff880222e8f628 0000000000000000 (.."............
ffff8802244c3d08: 0000000000000000 0000000000000002 ................
crash> struct rt_mutex ffff880222e8f628
struct rt_mutex {
wait_lock = {
raw_lock = {
slock = 65537
}
},
wait_list = {
node_list = {
next = 0xffff8802244c3d48,
prev = 0xffff8802244c3d48
}
},
owner = 0xffff880222f22c71,
save_state = 0
}
crash> bt 0xffff880222f22c70
PID: 10635 TASK: ffff880222f22c70 CPU: 3 COMMAND: "mount"
#0 [ffff8802216a9868] schedule at ffffffff8144584b
#1 [ffff8802216a9910] schedule_timeout at ffffffff81446865
#2 [ffff8802216a99a0] wait_for_common at ffffffff81445f74
#3 [ffff8802216a9a30] flush_work at ffffffff810712d3
CyanogenMod#4 [ffff8802216a9ab0] schedule_on_each_cpu at ffffffff81074463
CyanogenMod#5 [ffff8802216a9ae0] invalidate_bdev at ffffffff81178aba
CyanogenMod#6 [ffff8802216a9af0] vfs_load_quota_inode at ffffffff811a3632
CyanogenMod#7 [ffff8802216a9b50] dquot_quota_on_mount at ffffffff811a375c
#8 [ffff8802216a9b80] finish_unfinished at ffffffffa05dd8b0 [reiserfs]
#9 [ffff8802216a9cc0] reiserfs_fill_super at ffffffffa05de825 [reiserfs]
RIP: 00007f7b9303997a RSP: 00007ffff443c7a8 RFLAGS: 00010202
RAX: 00000000000000a5 RBX: ffffffff8144ef12 RCX: 00007f7b932e9ee0
RDX: 00007f7b93d9a400 RSI: 00007f7b93d9a3e0 RDI: 00007f7b93d9a3c0
RBP: 00007f7b93d9a2c0 R8: 00007f7b93d9a550 R9: 0000000000000001
R10: ffffffffc0ed040e R11: 0000000000000202 R12: 000000000000040e
R13: 0000000000000000 R14: 00000000c0ed040e R15: 00007ffff443ca20
ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b
Signed-off-by: Mike Galbraith <[email protected]>
Acked-by: Frederic Weisbecker <[email protected]>
Acked-by: Mike Galbraith <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Willy Tarreau <[email protected]>
Ahmed-Hady
pushed a commit
to Ahmed-Hady/android_kernel_motorola_msm8916
that referenced
this pull request
Aug 15, 2018
commit 3d46a44a0c01b15d385ccaae24b56f619613c256 upstream. PID: 614 TASK: ffff882a739da580 CPU: 3 COMMAND: "ocfs2dc" #0 [ffff882ecc3759b0] machine_kexec at ffffffff8103b35d #1 [ffff882ecc375a20] crash_kexec at ffffffff810b95b5 #2 [ffff882ecc375af0] oops_end at ffffffff815091d8 #3 [ffff882ecc375b20] die at ffffffff8101868b CyanogenMod#4 [ffff882ecc375b50] do_trap at ffffffff81508bb0 CyanogenMod#5 [ffff882ecc375ba0] do_invalid_op at ffffffff810165e5 CyanogenMod#6 [ffff882ecc375c40] invalid_op at ffffffff815116fb [exception RIP: ocfs2_ci_checkpointed+208] RIP: ffffffffa0a7e940 RSP: ffff882ecc375cf0 RFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000000000654b RCX: ffff8812dc83f1f8 RDX: 00000000000017d9 RSI: ffff8812dc83f1f8 RDI: ffffffffa0b2c318 RBP: ffff882ecc375d20 R8: ffff882ef6ecfa60 R9: ffff88301f272200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffffffffff R13: ffff8812dc83f4f0 R14: 0000000000000000 R15: ffff8812dc83f1f8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 CyanogenMod#7 [ffff882ecc375d28] ocfs2_check_meta_downconvert at ffffffffa0a7edbd [ocfs2] #8 [ffff882ecc375d38] ocfs2_unblock_lock at ffffffffa0a84af8 [ocfs2] #9 [ffff882ecc375dc8] ocfs2_process_blocked_lock at ffffffffa0a85285 [ocfs2] assert is tripped because the tran is not checkpointed and the lock level is PR. Some time ago, chmod command had been executed. As result, the following call chain left the inode cluster lock in PR state, latter on causing the assert. system_call_fastpath -> my_chmod -> sys_chmod -> sys_fchmodat -> notify_change -> ocfs2_setattr -> posix_acl_chmod -> ocfs2_iop_set_acl -> ocfs2_set_acl -> ocfs2_acl_set_mode Here is how. 1119 int ocfs2_setattr(struct dentry *dentry, struct iattr *attr) 1120 { 1247 ocfs2_inode_unlock(inode, 1); <<< WRONG thing to do. .. 1258 if (!status && attr->ia_valid & ATTR_MODE) { 1259 status = posix_acl_chmod(inode, inode->i_mode); 519 posix_acl_chmod(struct inode *inode, umode_t mode) 520 { .. 539 ret = inode->i_op->set_acl(inode, acl, ACL_TYPE_ACCESS); 287 int ocfs2_iop_set_acl(struct inode *inode, struct posix_acl *acl, ... 288 { 289 return ocfs2_set_acl(NULL, inode, NULL, type, acl, NULL, NULL); 224 int ocfs2_set_acl(handle_t *handle, 225 struct inode *inode, ... 231 { .. 252 ret = ocfs2_acl_set_mode(inode, di_bh, 253 handle, mode); 168 static int ocfs2_acl_set_mode(struct inode *inode, struct buffer_head ... 170 { 183 if (handle == NULL) { >>> BUG: inode lock not held in ex at this point <<< 184 handle = ocfs2_start_trans(OCFS2_SB(inode->i_sb), 185 OCFS2_INODE_UPDATE_CREDITS); ocfs2_setattr.#1247 we unlock and at #1259 call posix_acl_chmod. When we reach ocfs2_acl_set_mode.#181 and do trans, the inode cluster lock is not held in EX mode (it should be). How this could have happended? We are the lock master, were holding lock EX and have released it in ocfs2_setattr.#1247. Note that there are no holders of this lock at this point. Another node needs the lock in PR, and we downconvert from EX to PR. So the inode lock is PR when do the trans in ocfs2_acl_set_mode.#184. The trans stays in core (not flushed to disc). Now another node want the lock in EX, downconvert thread gets kicked (the one that tripped assert abovt), finds an unflushed trans but the lock is not EX (it is PR). If the lock was at EX, it would have flushed the trans ocfs2_ci_checkpointed -> ocfs2_start_checkpoint before downconverting (to NULL) for the request. ocfs2_setattr must not drop inode lock ex in this code path. If it does, takes it again before the trans, say in ocfs2_set_acl, another cluster node can get in between, execute another setattr, overwriting the one in progress on this node, resulting in a mode acl size combo that is a mix of the two. Orabug: 20189959 Signed-off-by: Tariq Saeed <[email protected]> Reviewed-by: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Joseph Qi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Willy Tarreau <[email protected]>
sultanqasim
pushed a commit
to moto8916/android_kernel_motorola_msm8916
that referenced
this pull request
Jan 13, 2019
[ Upstream commit 6900317f5eff0a7070c5936e5383f589e0de7a09 ]
David and HacKurx reported a following/similar size overflow triggered
in a grsecurity kernel, thanks to PaX's gcc size overflow plugin:
(Already fixed in later grsecurity versions by Brad and PaX Team.)
[ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314
cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr;
[ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ CyanogenMod#7
[ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...]
[ 1002.296153] ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8
[ 1002.296162] ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8
[ 1002.296169] ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60
[ 1002.296176] Call Trace:
[ 1002.296190] [<ffffffff818129ba>] dump_stack+0x45/0x57
[ 1002.296200] [<ffffffff8121f838>] report_size_overflow+0x38/0x60
[ 1002.296209] [<ffffffff816a979e>] scm_detach_fds+0x2ce/0x300
[ 1002.296220] [<ffffffff81791899>] unix_stream_read_generic+0x609/0x930
[ 1002.296228] [<ffffffff81791c9f>] unix_stream_recvmsg+0x4f/0x60
[ 1002.296236] [<ffffffff8178dc00>] ? unix_set_peek_off+0x50/0x50
[ 1002.296243] [<ffffffff8168fac7>] sock_recvmsg+0x47/0x60
[ 1002.296248] [<ffffffff81691522>] ___sys_recvmsg+0xe2/0x1e0
[ 1002.296257] [<ffffffff81693496>] __sys_recvmsg+0x46/0x80
[ 1002.296263] [<ffffffff816934fc>] SyS_recvmsg+0x2c/0x40
[ 1002.296271] [<ffffffff8181a3ab>] entry_SYSCALL_64_fastpath+0x12/0x85
Further investigation showed that this can happen when an *odd* number of
fds are being passed over AF_UNIX sockets.
In these cases CMSG_LEN(i * sizeof(int)) and CMSG_SPACE(i * sizeof(int)),
where i is the number of successfully passed fds, differ by 4 bytes due
to the extra CMSG_ALIGN() padding in CMSG_SPACE() to an 8 byte boundary
on 64 bit. The padding is used to align subsequent cmsg headers in the
control buffer.
When the control buffer passed in from the receiver side *lacks* these 4
bytes (e.g. due to buggy/wrong API usage), then msg->msg_controllen will
overflow in scm_detach_fds():
int cmlen = CMSG_LEN(i * sizeof(int)); <--- cmlen w/o tail-padding
err = put_user(SOL_SOCKET, &cm->cmsg_level);
if (!err)
err = put_user(SCM_RIGHTS, &cm->cmsg_type);
if (!err)
err = put_user(cmlen, &cm->cmsg_len);
if (!err) {
cmlen = CMSG_SPACE(i * sizeof(int)); <--- cmlen w/ 4 byte extra tail-padding
msg->msg_control += cmlen;
msg->msg_controllen -= cmlen; <--- iff no tail-padding space here ...
} ... wrap-around
F.e. it will wrap to a length of 18446744073709551612 bytes in case the
receiver passed in msg->msg_controllen of 20 bytes, and the sender
properly transferred 1 fd to the receiver, so that its CMSG_LEN results
in 20 bytes and CMSG_SPACE in 24 bytes.
In case of MSG_CMSG_COMPAT (scm_detach_fds_compat()), I haven't seen an
issue in my tests as alignment seems always on 4 byte boundary. Same
should be in case of native 32 bit, where we end up with 4 byte boundaries
as well.
In practice, passing msg->msg_controllen of 20 to recvmsg() while receiving
a single fd would mean that on successful return, msg->msg_controllen is
being set by the kernel to 24 bytes instead, thus more than the input
buffer advertised. It could f.e. become an issue if such application later
on zeroes or copies the control buffer based on the returned msg->msg_controllen
elsewhere.
Maximum number of fds we can send is a hard upper limit SCM_MAX_FD (253).
Going over the code, it seems like msg->msg_controllen is not being read
after scm_detach_fds() in scm_recv() anymore by the kernel, good!
Relevant recvmsg() handler are unix_dgram_recvmsg() (unix_seqpacket_recvmsg())
and unix_stream_recvmsg(). Both return back to their recvmsg() caller,
and ___sys_recvmsg() places the updated length, that is, new msg_control -
old msg_control pointer into msg->msg_controllen (hence the 24 bytes seen
in the example).
Long time ago, Wei Yongjun fixed something related in commit 1ac70e7
("[NET]: Fix function put_cmsg() which may cause usr application memory
overflow").
RFC3542, section 20.2. says:
The fields shown as "XX" are possible padding, between the cmsghdr
structure and the data, and between the data and the next cmsghdr
structure, if required by the implementation. While sending an
application may or may not include padding at the end of last
ancillary data in msg_controllen and implementations must accept both
as valid. On receiving a portable application must provide space for
padding at the end of the last ancillary data as implementations may
copy out the padding at the end of the control message buffer and
include it in the received msg_controllen. When recvmsg() is called
if msg_controllen is too small for all the ancillary data items
including any trailing padding after the last item an implementation
may set MSG_CTRUNC.
Since we didn't place MSG_CTRUNC for already quite a long time, just do
the same as in 1ac70e7 to avoid an overflow.
Btw, even man-page author got this wrong :/ See db939c9b26e9 ("cmsg.3: Fix
error in SCM_RIGHTS code sample"). Some people must have copied this (?),
thus it got triggered in the wild (reported several times during boot by
David and HacKurx).
No Fixes tag this time as pre 2002 (that is, pre history tree).
Reported-by: David Sterba <[email protected]>
Reported-by: HacKurx <[email protected]>
Cc: PaX Team <[email protected]>
Cc: Emese Revfy <[email protected]>
Cc: Brad Spengler <[email protected]>
Cc: Wei Yongjun <[email protected]>
Cc: Eric Dumazet <[email protected]>
Reviewed-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
sultanqasim
pushed a commit
to moto8916/android_kernel_motorola_msm8916
that referenced
this pull request
Jan 13, 2019
[ Upstream commit 6900317f5eff0a7070c5936e5383f589e0de7a09 ]
David and HacKurx reported a following/similar size overflow triggered
in a grsecurity kernel, thanks to PaX's gcc size overflow plugin:
(Already fixed in later grsecurity versions by Brad and PaX Team.)
[ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314
cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr;
[ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ CyanogenMod#7
[ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...]
[ 1002.296153] ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8
[ 1002.296162] ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8
[ 1002.296169] ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60
[ 1002.296176] Call Trace:
[ 1002.296190] [<ffffffff818129ba>] dump_stack+0x45/0x57
[ 1002.296200] [<ffffffff8121f838>] report_size_overflow+0x38/0x60
[ 1002.296209] [<ffffffff816a979e>] scm_detach_fds+0x2ce/0x300
[ 1002.296220] [<ffffffff81791899>] unix_stream_read_generic+0x609/0x930
[ 1002.296228] [<ffffffff81791c9f>] unix_stream_recvmsg+0x4f/0x60
[ 1002.296236] [<ffffffff8178dc00>] ? unix_set_peek_off+0x50/0x50
[ 1002.296243] [<ffffffff8168fac7>] sock_recvmsg+0x47/0x60
[ 1002.296248] [<ffffffff81691522>] ___sys_recvmsg+0xe2/0x1e0
[ 1002.296257] [<ffffffff81693496>] __sys_recvmsg+0x46/0x80
[ 1002.296263] [<ffffffff816934fc>] SyS_recvmsg+0x2c/0x40
[ 1002.296271] [<ffffffff8181a3ab>] entry_SYSCALL_64_fastpath+0x12/0x85
Further investigation showed that this can happen when an *odd* number of
fds are being passed over AF_UNIX sockets.
In these cases CMSG_LEN(i * sizeof(int)) and CMSG_SPACE(i * sizeof(int)),
where i is the number of successfully passed fds, differ by 4 bytes due
to the extra CMSG_ALIGN() padding in CMSG_SPACE() to an 8 byte boundary
on 64 bit. The padding is used to align subsequent cmsg headers in the
control buffer.
When the control buffer passed in from the receiver side *lacks* these 4
bytes (e.g. due to buggy/wrong API usage), then msg->msg_controllen will
overflow in scm_detach_fds():
int cmlen = CMSG_LEN(i * sizeof(int)); <--- cmlen w/o tail-padding
err = put_user(SOL_SOCKET, &cm->cmsg_level);
if (!err)
err = put_user(SCM_RIGHTS, &cm->cmsg_type);
if (!err)
err = put_user(cmlen, &cm->cmsg_len);
if (!err) {
cmlen = CMSG_SPACE(i * sizeof(int)); <--- cmlen w/ 4 byte extra tail-padding
msg->msg_control += cmlen;
msg->msg_controllen -= cmlen; <--- iff no tail-padding space here ...
} ... wrap-around
F.e. it will wrap to a length of 18446744073709551612 bytes in case the
receiver passed in msg->msg_controllen of 20 bytes, and the sender
properly transferred 1 fd to the receiver, so that its CMSG_LEN results
in 20 bytes and CMSG_SPACE in 24 bytes.
In case of MSG_CMSG_COMPAT (scm_detach_fds_compat()), I haven't seen an
issue in my tests as alignment seems always on 4 byte boundary. Same
should be in case of native 32 bit, where we end up with 4 byte boundaries
as well.
In practice, passing msg->msg_controllen of 20 to recvmsg() while receiving
a single fd would mean that on successful return, msg->msg_controllen is
being set by the kernel to 24 bytes instead, thus more than the input
buffer advertised. It could f.e. become an issue if such application later
on zeroes or copies the control buffer based on the returned msg->msg_controllen
elsewhere.
Maximum number of fds we can send is a hard upper limit SCM_MAX_FD (253).
Going over the code, it seems like msg->msg_controllen is not being read
after scm_detach_fds() in scm_recv() anymore by the kernel, good!
Relevant recvmsg() handler are unix_dgram_recvmsg() (unix_seqpacket_recvmsg())
and unix_stream_recvmsg(). Both return back to their recvmsg() caller,
and ___sys_recvmsg() places the updated length, that is, new msg_control -
old msg_control pointer into msg->msg_controllen (hence the 24 bytes seen
in the example).
Long time ago, Wei Yongjun fixed something related in commit 1ac70e7
("[NET]: Fix function put_cmsg() which may cause usr application memory
overflow").
RFC3542, section 20.2. says:
The fields shown as "XX" are possible padding, between the cmsghdr
structure and the data, and between the data and the next cmsghdr
structure, if required by the implementation. While sending an
application may or may not include padding at the end of last
ancillary data in msg_controllen and implementations must accept both
as valid. On receiving a portable application must provide space for
padding at the end of the last ancillary data as implementations may
copy out the padding at the end of the control message buffer and
include it in the received msg_controllen. When recvmsg() is called
if msg_controllen is too small for all the ancillary data items
including any trailing padding after the last item an implementation
may set MSG_CTRUNC.
Since we didn't place MSG_CTRUNC for already quite a long time, just do
the same as in 1ac70e7 to avoid an overflow.
Btw, even man-page author got this wrong :/ See db939c9b26e9 ("cmsg.3: Fix
error in SCM_RIGHTS code sample"). Some people must have copied this (?),
thus it got triggered in the wild (reported several times during boot by
David and HacKurx).
No Fixes tag this time as pre 2002 (that is, pre history tree).
Reported-by: David Sterba <[email protected]>
Reported-by: HacKurx <[email protected]>
Cc: PaX Team <[email protected]>
Cc: Emese Revfy <[email protected]>
Cc: Brad Spengler <[email protected]>
Cc: Wei Yongjun <[email protected]>
Cc: Eric Dumazet <[email protected]>
Reviewed-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
sultanqasim
pushed a commit
to moto8916/android_kernel_motorola_msm8916
that referenced
this pull request
Jan 13, 2019
[ Upstream commit 6900317f5eff0a7070c5936e5383f589e0de7a09 ]
David and HacKurx reported a following/similar size overflow triggered
in a grsecurity kernel, thanks to PaX's gcc size overflow plugin:
(Already fixed in later grsecurity versions by Brad and PaX Team.)
[ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314
cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr;
[ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ CyanogenMod#7
[ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...]
[ 1002.296153] ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8
[ 1002.296162] ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8
[ 1002.296169] ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60
[ 1002.296176] Call Trace:
[ 1002.296190] [<ffffffff818129ba>] dump_stack+0x45/0x57
[ 1002.296200] [<ffffffff8121f838>] report_size_overflow+0x38/0x60
[ 1002.296209] [<ffffffff816a979e>] scm_detach_fds+0x2ce/0x300
[ 1002.296220] [<ffffffff81791899>] unix_stream_read_generic+0x609/0x930
[ 1002.296228] [<ffffffff81791c9f>] unix_stream_recvmsg+0x4f/0x60
[ 1002.296236] [<ffffffff8178dc00>] ? unix_set_peek_off+0x50/0x50
[ 1002.296243] [<ffffffff8168fac7>] sock_recvmsg+0x47/0x60
[ 1002.296248] [<ffffffff81691522>] ___sys_recvmsg+0xe2/0x1e0
[ 1002.296257] [<ffffffff81693496>] __sys_recvmsg+0x46/0x80
[ 1002.296263] [<ffffffff816934fc>] SyS_recvmsg+0x2c/0x40
[ 1002.296271] [<ffffffff8181a3ab>] entry_SYSCALL_64_fastpath+0x12/0x85
Further investigation showed that this can happen when an *odd* number of
fds are being passed over AF_UNIX sockets.
In these cases CMSG_LEN(i * sizeof(int)) and CMSG_SPACE(i * sizeof(int)),
where i is the number of successfully passed fds, differ by 4 bytes due
to the extra CMSG_ALIGN() padding in CMSG_SPACE() to an 8 byte boundary
on 64 bit. The padding is used to align subsequent cmsg headers in the
control buffer.
When the control buffer passed in from the receiver side *lacks* these 4
bytes (e.g. due to buggy/wrong API usage), then msg->msg_controllen will
overflow in scm_detach_fds():
int cmlen = CMSG_LEN(i * sizeof(int)); <--- cmlen w/o tail-padding
err = put_user(SOL_SOCKET, &cm->cmsg_level);
if (!err)
err = put_user(SCM_RIGHTS, &cm->cmsg_type);
if (!err)
err = put_user(cmlen, &cm->cmsg_len);
if (!err) {
cmlen = CMSG_SPACE(i * sizeof(int)); <--- cmlen w/ 4 byte extra tail-padding
msg->msg_control += cmlen;
msg->msg_controllen -= cmlen; <--- iff no tail-padding space here ...
} ... wrap-around
F.e. it will wrap to a length of 18446744073709551612 bytes in case the
receiver passed in msg->msg_controllen of 20 bytes, and the sender
properly transferred 1 fd to the receiver, so that its CMSG_LEN results
in 20 bytes and CMSG_SPACE in 24 bytes.
In case of MSG_CMSG_COMPAT (scm_detach_fds_compat()), I haven't seen an
issue in my tests as alignment seems always on 4 byte boundary. Same
should be in case of native 32 bit, where we end up with 4 byte boundaries
as well.
In practice, passing msg->msg_controllen of 20 to recvmsg() while receiving
a single fd would mean that on successful return, msg->msg_controllen is
being set by the kernel to 24 bytes instead, thus more than the input
buffer advertised. It could f.e. become an issue if such application later
on zeroes or copies the control buffer based on the returned msg->msg_controllen
elsewhere.
Maximum number of fds we can send is a hard upper limit SCM_MAX_FD (253).
Going over the code, it seems like msg->msg_controllen is not being read
after scm_detach_fds() in scm_recv() anymore by the kernel, good!
Relevant recvmsg() handler are unix_dgram_recvmsg() (unix_seqpacket_recvmsg())
and unix_stream_recvmsg(). Both return back to their recvmsg() caller,
and ___sys_recvmsg() places the updated length, that is, new msg_control -
old msg_control pointer into msg->msg_controllen (hence the 24 bytes seen
in the example).
Long time ago, Wei Yongjun fixed something related in commit 1ac70e7
("[NET]: Fix function put_cmsg() which may cause usr application memory
overflow").
RFC3542, section 20.2. says:
The fields shown as "XX" are possible padding, between the cmsghdr
structure and the data, and between the data and the next cmsghdr
structure, if required by the implementation. While sending an
application may or may not include padding at the end of last
ancillary data in msg_controllen and implementations must accept both
as valid. On receiving a portable application must provide space for
padding at the end of the last ancillary data as implementations may
copy out the padding at the end of the control message buffer and
include it in the received msg_controllen. When recvmsg() is called
if msg_controllen is too small for all the ancillary data items
including any trailing padding after the last item an implementation
may set MSG_CTRUNC.
Since we didn't place MSG_CTRUNC for already quite a long time, just do
the same as in 1ac70e7 to avoid an overflow.
Btw, even man-page author got this wrong :/ See db939c9b26e9 ("cmsg.3: Fix
error in SCM_RIGHTS code sample"). Some people must have copied this (?),
thus it got triggered in the wild (reported several times during boot by
David and HacKurx).
No Fixes tag this time as pre 2002 (that is, pre history tree).
Reported-by: David Sterba <[email protected]>
Reported-by: HacKurx <[email protected]>
Cc: PaX Team <[email protected]>
Cc: Emese Revfy <[email protected]>
Cc: Brad Spengler <[email protected]>
Cc: Wei Yongjun <[email protected]>
Cc: Eric Dumazet <[email protected]>
Reviewed-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
sultanqasim
pushed a commit
to moto8916/android_kernel_motorola_msm8916
that referenced
this pull request
Jan 13, 2019
[ Upstream commit 6900317f5eff0a7070c5936e5383f589e0de7a09 ]
David and HacKurx reported a following/similar size overflow triggered
in a grsecurity kernel, thanks to PaX's gcc size overflow plugin:
(Already fixed in later grsecurity versions by Brad and PaX Team.)
[ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314
cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr;
[ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ CyanogenMod#7
[ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...]
[ 1002.296153] ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8
[ 1002.296162] ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8
[ 1002.296169] ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60
[ 1002.296176] Call Trace:
[ 1002.296190] [<ffffffff818129ba>] dump_stack+0x45/0x57
[ 1002.296200] [<ffffffff8121f838>] report_size_overflow+0x38/0x60
[ 1002.296209] [<ffffffff816a979e>] scm_detach_fds+0x2ce/0x300
[ 1002.296220] [<ffffffff81791899>] unix_stream_read_generic+0x609/0x930
[ 1002.296228] [<ffffffff81791c9f>] unix_stream_recvmsg+0x4f/0x60
[ 1002.296236] [<ffffffff8178dc00>] ? unix_set_peek_off+0x50/0x50
[ 1002.296243] [<ffffffff8168fac7>] sock_recvmsg+0x47/0x60
[ 1002.296248] [<ffffffff81691522>] ___sys_recvmsg+0xe2/0x1e0
[ 1002.296257] [<ffffffff81693496>] __sys_recvmsg+0x46/0x80
[ 1002.296263] [<ffffffff816934fc>] SyS_recvmsg+0x2c/0x40
[ 1002.296271] [<ffffffff8181a3ab>] entry_SYSCALL_64_fastpath+0x12/0x85
Further investigation showed that this can happen when an *odd* number of
fds are being passed over AF_UNIX sockets.
In these cases CMSG_LEN(i * sizeof(int)) and CMSG_SPACE(i * sizeof(int)),
where i is the number of successfully passed fds, differ by 4 bytes due
to the extra CMSG_ALIGN() padding in CMSG_SPACE() to an 8 byte boundary
on 64 bit. The padding is used to align subsequent cmsg headers in the
control buffer.
When the control buffer passed in from the receiver side *lacks* these 4
bytes (e.g. due to buggy/wrong API usage), then msg->msg_controllen will
overflow in scm_detach_fds():
int cmlen = CMSG_LEN(i * sizeof(int)); <--- cmlen w/o tail-padding
err = put_user(SOL_SOCKET, &cm->cmsg_level);
if (!err)
err = put_user(SCM_RIGHTS, &cm->cmsg_type);
if (!err)
err = put_user(cmlen, &cm->cmsg_len);
if (!err) {
cmlen = CMSG_SPACE(i * sizeof(int)); <--- cmlen w/ 4 byte extra tail-padding
msg->msg_control += cmlen;
msg->msg_controllen -= cmlen; <--- iff no tail-padding space here ...
} ... wrap-around
F.e. it will wrap to a length of 18446744073709551612 bytes in case the
receiver passed in msg->msg_controllen of 20 bytes, and the sender
properly transferred 1 fd to the receiver, so that its CMSG_LEN results
in 20 bytes and CMSG_SPACE in 24 bytes.
In case of MSG_CMSG_COMPAT (scm_detach_fds_compat()), I haven't seen an
issue in my tests as alignment seems always on 4 byte boundary. Same
should be in case of native 32 bit, where we end up with 4 byte boundaries
as well.
In practice, passing msg->msg_controllen of 20 to recvmsg() while receiving
a single fd would mean that on successful return, msg->msg_controllen is
being set by the kernel to 24 bytes instead, thus more than the input
buffer advertised. It could f.e. become an issue if such application later
on zeroes or copies the control buffer based on the returned msg->msg_controllen
elsewhere.
Maximum number of fds we can send is a hard upper limit SCM_MAX_FD (253).
Going over the code, it seems like msg->msg_controllen is not being read
after scm_detach_fds() in scm_recv() anymore by the kernel, good!
Relevant recvmsg() handler are unix_dgram_recvmsg() (unix_seqpacket_recvmsg())
and unix_stream_recvmsg(). Both return back to their recvmsg() caller,
and ___sys_recvmsg() places the updated length, that is, new msg_control -
old msg_control pointer into msg->msg_controllen (hence the 24 bytes seen
in the example).
Long time ago, Wei Yongjun fixed something related in commit 1ac70e7
("[NET]: Fix function put_cmsg() which may cause usr application memory
overflow").
RFC3542, section 20.2. says:
The fields shown as "XX" are possible padding, between the cmsghdr
structure and the data, and between the data and the next cmsghdr
structure, if required by the implementation. While sending an
application may or may not include padding at the end of last
ancillary data in msg_controllen and implementations must accept both
as valid. On receiving a portable application must provide space for
padding at the end of the last ancillary data as implementations may
copy out the padding at the end of the control message buffer and
include it in the received msg_controllen. When recvmsg() is called
if msg_controllen is too small for all the ancillary data items
including any trailing padding after the last item an implementation
may set MSG_CTRUNC.
Since we didn't place MSG_CTRUNC for already quite a long time, just do
the same as in 1ac70e7 to avoid an overflow.
Btw, even man-page author got this wrong :/ See db939c9b26e9 ("cmsg.3: Fix
error in SCM_RIGHTS code sample"). Some people must have copied this (?),
thus it got triggered in the wild (reported several times during boot by
David and HacKurx).
No Fixes tag this time as pre 2002 (that is, pre history tree).
Reported-by: David Sterba <[email protected]>
Reported-by: HacKurx <[email protected]>
Cc: PaX Team <[email protected]>
Cc: Emese Revfy <[email protected]>
Cc: Brad Spengler <[email protected]>
Cc: Wei Yongjun <[email protected]>
Cc: Eric Dumazet <[email protected]>
Reviewed-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.