aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* fs/nfs: Fix nfs_parse_devname to not modify it's argumentHEADng-7.1.2Eric W. Biederman2019-09-131-1/+1
| | | | | | | | | | | | | | | commit 40cc394be1aa18848b8757e03bd8ed23281f572e upstream. In the rare and unsupported case of a hostname list nfs_parse_devname will modify dev_name. There is no need to modify dev_name as the all that is being computed is the length of the hostname, so the computed length can just be shorted. Fixes: dc04589827f7 ("NFS: Use common device name parsing logic for NFSv4 and NFSv2/v3") Change-Id: Ie215b7b91559b086511accbc42f345f78dac19b3 Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* udf: fix mismergeMoyster2019-09-131-1/+0
|
* dccp: Fix memleak in __feat_register_spYueHaibing2019-09-111-1/+6
| | | | | | | | | | | | | | | commit 1d3ff0950e2b40dc861b1739029649d03f591820 upstream. If dccp_feat_push_change fails, we forget free the mem which is alloced by kmemdup in dccp_feat_clone_sp_val. Change-Id: Ic25864978afcc0ad49b5580b62a6030a866e9efa Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: e8ef967a54f4 ("dccp: Registration routines for changing feature values") Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* Bluetooth: Fix faulty expression for minimum encryption key size checkMatias Karhumaa2019-09-111-1/+1
| | | | | | | | | | | | | | | | | | | commit eca94432934fe5f141d084f2e36ee2c0e614cc04 upstream. Fix minimum encryption key size check so that HCI_MIN_ENC_KEY_SIZE is also allowed as stated in the comment. This bug caused connection problems with devices having maximum encryption key size of 7 octets (56-bit). Fixes: 693cd8ce3f88 ("Bluetooth: Fix regression with minimum encryption key size alignment") Change-Id: I62cf3d0d4789d5ffca377597c9e2752aa896d834 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203997 Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Bluetooth: Check state in l2cap_disconnect_rspMatias Karhumaa2019-09-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 28261da8a26f4915aa257d12d506c6ba179d961f ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame #402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 #394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 #397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 #403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 #407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Change-Id: I01079eb551ee11d08f9a76d6070e1b3a75f4f421 Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ext4: fix data corruption caused by unaligned direct AIOLukas Czerner2019-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 372a03e01853f860560eade508794dd274e9b390 upstream. Ext4 needs to serialize unaligned direct AIO because the zeroing of partial blocks of two competing unaligned AIOs can result in data corruption. However it decides not to serialize if the potentially unaligned aio is past i_size with the rationale that no pending writes are possible past i_size. Unfortunately if the i_size is not block aligned and the second unaligned write lands past i_size, but still into the same block, it has the potential of corrupting the previous unaligned write to the same block. This is (very simplified) reproducer from Frank // 41472 = (10 * 4096) + 512 // 37376 = 41472 - 4096 ftruncate(fd, 41472); io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376); io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472); io_submit(io_ctx, 1, &iocbs[1]); io_submit(io_ctx, 1, &iocbs[2]); io_getevents(io_ctx, 2, 2, events, NULL); Without this patch the 512B range from 40960 up to the start of the second unaligned write (41472) is going to be zeroed overwriting the data written by the first write. This is a data corruption. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 With this patch the data corruption is avoided because we will recognize the unaligned_aio and wait for the unwritten extent conversion. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 * 0000b200 Change-Id: Ieba4f68394668c4354bb4346b5d1d32159968d17 Reported-by: Frank Sorenson <fsorenso@redhat.com> Signed-off-by: Lukas Czerner <lczerner@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* NFS: fix mount/umount race in nlmclnt.NeilBrown2019-09-111-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | commit 4a9be28c45bf02fa0436808bb6c0baeba30e120e upstream. If the last NFSv3 unmount from a given host races with a mount from the same host, we can destroy an nlm_host that is still in use. Specifically nlmclnt_lookup_host() can increment h_count on an nlm_host that nlmclnt_release_host() has just successfully called refcount_dec_and_test() on. Once nlmclnt_lookup_host() drops the mutex, nlm_destroy_host_lock() will be called to destroy the nlmclnt which is now in use again. The cause of the problem is that the dec_and_test happens outside the locked region. This is easily fixed by using refcount_dec_and_mutex_lock(). Fixes: 8ea6ecc8b075 ("lockd: Create client-side nlm_host cache") Change-Id: I37405cb4379c96c2ca9780beaa916067e6aab7b3 Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> [bwh: Backported to 3.16: use atomic instead of refcount API] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* udf: Fix crash on IO error during truncateJan Kara2019-09-111-0/+3
| | | | | | | | | | | | | | | | | commit d3ca4651d05c0ff7259d087d8c949bcf3e14fb46 upstream. When truncate(2) hits IO error when reading indirect extent block the code just bugs with: kernel BUG at linux-4.15.0/fs/udf/truncate.c:249! ... Fix the problem by bailing out cleanly in case of IO error. Change-Id: Ic11c99c11bc88c7a97f9b7cd741f13b8248fd925 Reported-by: jean-luc malet <jeanluc.malet@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* Bluetooth: hci_uart: check for missing tty operationsVladis Dronov2019-09-113-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b36a1552d7319bbfd5cf7f08726c23c5c66d4f73 upstream. Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset() functions which are called by the certain HCI UART protocols (hci_ath, hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control() or directly. This leads to an execution at NULL and can be triggered by an unprivileged user. Fix this by adding a helper function and a check for the missing tty operations in the protocols code. This fixes CVE-2019-10207. The Fixes: lines list commits where calls to tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART protocols. Change-Id: Ia8a38211661570912e9969262af239c021a13d5f Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50 Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial chip") Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions") Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate configuration support") Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support") Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Signed-off-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Yu-Chen, Cho <acho@suse.com> Tested-by: Yu-Chen, Cho <acho@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [bwh: Backported to 3.16: - Only hci_ath is affected - There is no serdev support] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* ALSA: pcm: Fix possible OOB access in PCM oss pluginsTakashi Iwai2019-09-111-21/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ca0214ee2802dd47239a4e39fb21c5b00ef61b22 upstream. The PCM OSS emulation converts and transfers the data on the fly via "plugins". The data is converted over the dynamically allocated buffer for each plugin, and recently syzkaller caught OOB in this flow. Although the bisection by syzbot pointed out to the commit 65766ee0bf7f ("ALSA: oss: Use kvzalloc() for local buffer allocations"), this is merely a commit to replace vmalloc() with kvmalloc(), hence it can't be the cause. The further debug action revealed that this happens in the case where a slave PCM doesn't support only the stereo channels while the OSS stream is set up for a mono channel. Below is a brief explanation: At each OSS parameter change, the driver sets up the PCM hw_params again in snd_pcm_oss_change_params_lock(). This is also the place where plugins are created and local buffers are allocated. The problem is that the plugins are created before the final hw_params is determined. Namely, two snd_pcm_hw_param_near() calls for setting the period size and periods may influence on the final result of channels, rates, etc, too, while the current code has already created plugins beforehand with the premature values. So, the plugin believes that channels=1, while the actual I/O is with channels=2, which makes the driver reading/writing over the allocated buffer size. The fix is simply to move the plugin allocation code after the final hw_params call. Change-Id: Iba66743ab3e8152be10104432758f6994941a10d Reported-by: syzbot+d4503ae45b65c5bc1194@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* futex: Ensure that futex address is aligned in handle_futex_death()Chen Jie2019-09-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | commit 5a07168d8d89b00fe1760120714378175b3ef992 upstream. The futex code requires that the user space addresses of futexes are 32bit aligned. sys_futex() checks this in futex_get_keys() but the robust list code has no alignment check in place. As a consequence the kernel crashes on architectures with strict alignment requirements in handle_futex_death() when trying to cmpxchg() on an unaligned futex address which was retrieved from the robust list. [ tglx: Rewrote changelog, proper sizeof() based alignement check and add comment ] Fixes: 0771dfefc9e5 ("[PATCH] lightweight robust futexes: core") Change-Id: Ia19dbc196f5debc3c506f7d65fc2e155c835703d Signed-off-by: Chen Jie <chenjie6@huawei.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: <dvhart@infradead.org> Cc: <peterz@infradead.org> Cc: <zengweilin@huawei.com> Link: https://lkml.kernel.org/r/1552621478-119787-1-git-send-email-chenjie6@huawei.com Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* ALSA: seq: oss: Fix Spectre v1 vulnerabilityGustavo A. R. Silva2019-09-111-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | commit c709f14f0616482b67f9fbcb965e1493a03ff30b upstream. dev is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap) Fix this by sanitizing dev before using it to index dp->synths. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Change-Id: Iee6ea225b165fec2d01a09c5d24eea22099a3a53 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* ALSA: rawmidi: Fix potential Spectre v1 vulnerabilityGustavo A. R. Silva2019-09-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 2b1d9c8f87235f593826b9cf46ec10247741fff9 upstream. info->stream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre issue 'rmidi->streams' [r] (local cap) Fix this by sanitizing info->stream before using it to index rmidi->streams. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Change-Id: I2c8b93b82ad4374027a03dc4c73fdf74eee696e6 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* packet: in recvmsg msg_name return at least sizeof sockaddr_llWillem de Bruijn2019-08-131-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | commit b2cf86e1563e33a14a1c69b3e508d15dc12f804c upstream. Packet send checks that msg_name is at least sizeof sockaddr_ll. Packet recv must return at least this length, so that its output can be passed unmodified to packet send. This ceased to be true since adding support for lladdr longer than sll_addr. Since, the return value uses true address length. Always return at least sizeof sockaddr_ll, even if address length is shorter. Zero the padding bytes. Change v1->v2: do not overwrite zeroed padding again. use copy_len. Fixes: 0fb375fb9b93 ("[AF_PACKET]: Allow for > 8 byte hardware addresses.") Change-Id: I79749bc43e8dab934165e8ff13c2d3bf883287ff Suggested-by: David Laight <David.Laight@aculab.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* net-sysfs: Fix memory leak in netdev_register_kobjectWang Hai2019-08-131-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6b70fc94afd165342876e53fc4b2f7d085009945 upstream. When registering struct net_device, it will call register_netdevice -> netdev_register_kobject -> device_initialize(dev); dev_set_name(dev, "%s", ndev->name) device_add(dev) register_queue_kobjects(ndev) In netdev_register_kobject(), if device_add(dev) or register_queue_kobjects(ndev) failed. Register_netdevice() will return error, causing netdev_freemem(ndev) to be called to free net_device, however put_device(&dev->dev)->..-> kobject_cleanup() won't be called, resulting in a memory leak. syzkaller report this: BUG: memory leak unreferenced object 0xffff8881f4fad168 (size 8): comm "syz-executor.0", pid 3575, jiffies 4294778002 (age 20.134s) hex dump (first 8 bytes): 77 70 61 6e 30 00 ff ff wpan0... backtrace: [<000000006d2d91d7>] kstrdup_const+0x3d/0x50 mm/util.c:73 [<00000000ba9ff953>] kvasprintf_const+0x112/0x170 lib/kasprintf.c:48 [<000000005555ec09>] kobject_set_name_vargs+0x55/0x130 lib/kobject.c:281 [<0000000098d28ec3>] dev_set_name+0xbb/0xf0 drivers/base/core.c:1915 [<00000000b7553017>] netdev_register_kobject+0xc0/0x410 net/core/net-sysfs.c:1727 [<00000000c826a797>] register_netdevice+0xa51/0xeb0 net/core/dev.c:8711 [<00000000857bfcfd>] cfg802154_update_iface_num.isra.2+0x13/0x90 [ieee802154] [<000000003126e453>] ieee802154_llsec_fill_key_id+0x1d5/0x570 [ieee802154] [<00000000e4b3df51>] 0xffffffffc1500e0e [<00000000b4319776>] platform_drv_probe+0xc6/0x180 drivers/base/platform.c:614 [<0000000037669347>] really_probe+0x491/0x7c0 drivers/base/dd.c:509 [<000000008fed8862>] driver_probe_device+0xdc/0x240 drivers/base/dd.c:671 [<00000000baf52041>] device_driver_attach+0xf2/0x130 drivers/base/dd.c:945 [<00000000c7cc8dec>] __driver_attach+0x10e/0x210 drivers/base/dd.c:1022 [<0000000057a757c2>] bus_for_each_dev+0x154/0x1e0 drivers/base/bus.c:304 [<000000005f5ae04b>] bus_add_driver+0x427/0x5e0 drivers/base/bus.c:645 Change-Id: I7f0b3c1f1747a2b387a697f3a2f3e6ac80d34e08 Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Wang Hai <wanghai26@huawei.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* UPSTREAM: timer: Export destroy_hrtimer_on_stack()Guenter Roeck2019-08-011-0/+1
| | | | | | | | | | | | | | | hrtimer_init_on_stack() needs a matching call to destroy_hrtimer_on_stack(), so both need to be exported. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit c08376ac97cb202ec65320f3d90d5c4c5e2adb0b) [astrachan: Fixes {i386,amd64}-allmodconfig build failure in vsoc.ko noticed by kernelci.org project building kernel/common] Bug: 79376877 Change-Id: If4d5c466255019322ea21ef38ee5b1b382cce969 Signed-off-by: Alistair Strachan <astrachan@google.com> Signed-off-by: Moyster <oysterized@gmail.com>
* Security Patch: mt_idle: avoid sscanf heap overflowPiazza Lo2019-08-011-5/+5
| | | | | | | | | | | | | | [Detail] To add buffer size limitation in sscanf(%s) M-ALPS03353869 CVE-2017-0827 BUG:65994220 Change-Id: Icebd9e86ca533dcd5425ed89c0488a64ed921f75 Signed-off-by: Piazza Lo <piazza.lo@mediatek.com> Signed-off-by: Moyster <oysterized@gmail.com>
* defconfig: remove useless usb storage stuffMoyster2019-08-011-11/+11
|
* fs: sdfat: remove unused counter when delayed metadata dirty is disabledNanda Okitavera2019-08-011-0/+4
| | | | Signed-off-by: Nanda Okitavera <codeharuka.yusa@gmail.com>
* fs: sdfat: Disable by defaultLuca Stefani2019-08-011-1/+0
|
* defconfig: remove unused comp algosMoyster2019-08-011-4/+2
|
* kernel: don't use ccache to build kernelMoyster2019-08-011-2/+2
|
* (CR) ALPS03957020(For_mt6737m_35_n1_alps-mp-n1.mp1-V1_P118)lingsen12019-07-201-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch Type: Customer Request CR ID: ALPS03957020 Severity: Description: [Patch Request] [PMS] mt, Project: mt6737M_35_N1, SW Version: alps-mp-n1.mp1-V1N/A Associated Files: device/mt/mt6737m_35_n1/ProjectConfig.mk Patch Type: Customer Request CR ID: ALPS03913671 Severity: Critical Description: [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[Title fo***ustomer]] [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[Problem Description]] [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[問題現象]] [Google Security P***h][CVE_2018_9369]EoP Vulnerability i***ootloader (Device Specific) [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: vendor/mediatek/proprietary/bootable/bootloader/lk/app/mt_boot/fastboot.c Patch Type: Customer Request CR ID: ALPS03913728 Severity: Critical Description: [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[Title fo***ustomer]] [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[Problem Description]] [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[問題現象]] [Google Security P***h][CVE_2018_9394]EoP Vulnerability in P2P (Device Specific) [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: kernel-3.18/drivers/misc/mediatek/connectivity/wlan/gen2/os/linux/gl_p2p.c Patch Type: Customer Request CR ID: ALPS03913732 Severity: Critical Description: [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[Title fo***ustomer]] [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[Problem Description]] [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[問題現象]] [Google Security P***h][CVE_2018_9396]EoP Vulnerability in C*** (Device Specific) [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: kernel-3.18/drivers/misc/mediatek/eccci/port_rpc.c Patch Type: Customer Request CR ID: ALPS03921114 Severity: Critical Description: [IMS ***erface][version#0x68][AP] Added support fo***ountry-specific ur***o***o call response [[Title fo***ustomer]] IMS ***erface to support country-specific URN [[Problem Description]] Added support for IMS ***erface mo_call_c*** to country-specific URN which I***tack may send to MD side. [[Potential Impa*** of the solution]] Emergency call fun***ionality possible to implement as per ***PP and operator requirement. [[Modules to be verified after taking p***h]] VDM, VoLTE UA [[問題標題]] IMS ***erface to support country-specific URN [[問題現象]] Added support for IMS ***erface mo_call_c*** to country-specific URN which I***tack may send to MD side. [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) Emergency call fun***ionality possible to implement as per ***PP and operator requirement. [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) VDM, VoLTE UAN/A Associated Files: vendor/mt/libs/volte_imcb/arm/volte_imcb vendor/mt/libs/volte_stack/arm/volte_stack vendor/mt/libs/volte_ua/arm/volte_ua Change-Id: I0b947e82a40c6d2f7f63069ea73023cd61056223
* (CR) ALPS03877842(For_mt6737m_35_n1_alps-mp-n1.mp1-V1_P113)lingsen12019-07-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch Type: Customer Request CR ID: ALPS03877842 Severity: Description: [Patch Request] [PMS] mt, Project: mt6737M_35_N1, SW Version: alps-mp-n1.mp1-V1N/A Associated Files: device/mt/mt6737m_35_n1/ProjectConfig.mk vendor/mt/libs/libmtk-art-runtime/arm/libmtk-art-runtime.a Patch Type: Customer Request CR ID: ALPS03683903 Severity: Critical Description: [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[Title fo***ustomer]] [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[Problem Description]] [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[Potential Impa*** of the solution]] No [[Modules to be verified after taking p***h]] No [[問題標題]] [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[問題現象]] [Buganizer]Security Vulnerability Issue 70515752 - [An***d GO Pen***ing] Mediatek Preloader Allows Arbitrary Peripheral Memory Reads and Writes [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) No [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoN/A Associated Files: vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/core/download.c vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/core/inc/download.h vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/drivers/inc/mt6735.h vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/security/inc/sec_region.h vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/security/sec_region.c Patch Type: Customer Request CR ID: ALPS03693488 Severity: Critical Description: [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader ¡§Download Mode¡¨ Memory Corruption [[Title fo***ustomer]] [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader Download Mode Memory Corruption [[Problem Description]] [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader Download Mode Memory Corruption [[Potential Impa*** of the solution]] no [[Modules to be verified after taking p***h]] boot [[問題標題]] [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader Download Mode Memory Corruption [[問題現象]] [Buganizer]Security Vulnerability Issue 70515281 - [An***d GO Pen***ing] Mediatek Preloader Download Mode Memory Corruption [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) no [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) bootN/A Associated Files: vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/link_descriptor.ld vendor/mediatek/proprietary/bootable/bootloader/preloader/platform/mt6735/src/core/partition.c Patch Type: Customer Request CR ID: ALPS03740330 Severity: Critical Description: [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[Title fo***ustomer]] [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[Problem Description]] [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[問題現象]] [Buganizer]Security Vulnerability Issue 71867247 - [An***d GO Pen***ing] - Remo***emory Corruption in Mediatek WiFi TLDS Frame Parser [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: kernel-3.18/drivers/misc/mediatek/connectivity/wlan/gen2/mgmt/tdls.c Patch Type: Customer Request CR ID: ALPS03862169 Severity: Critical Description: [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[Title fo***ustomer]] [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[Problem Description]] [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[問題現象]] [Google Security P***h][CVE_2017_13311]EoP Vulnerability in ProcessStats [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: frameworks/base/core/java/com/android/internal/app/procstats/SparseMappingTable.java Patch Type: Customer Request CR ID: ALPS03862180 Severity: Critical Description: [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[Title fo***ustomer]] [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[Problem Description]] [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[問題現象]] [Google Security P***h][CVE_2017_13316]ID Vulnerability in Speech recognizer [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: frameworks/base/core/java/android/content/PermissionChecker.java frameworks/base/core/java/android/speech/RecognitionService.java Patch Type: Customer Request CR ID: ALPS03862195 Severity: Critical Description: [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[Title fo***ustomer]] [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[Problem Description]] [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[問題現象]] [Google Security P***h][CVE_2017_13319]ID/DoS Vulnerability in MP3 codec [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: frameworks/av/media/libstagefright/codecs/mp3dec/src/pvmp3_decode_header.cpp Patch Type: Customer Request CR ID: ALPS03862206 Severity: Critical Description: [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[Title fo***ustomer]] [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[Problem Description]] [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[Potential Impa*** of the solution]] None [[Modules to be verified after taking p***h]] None [[問題標題]] [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[問題現象]] [Google Security P***h][CVE_2017_16643]ID Vulnerability in USB driver (Device Specific) [[解法可能帶來的影響]] (請填寫於此行下方，並描述如果合入這個p***h可能會有什麼trade off的改變，如perfo******e降低、UI改變等等) None [[建議驗證模塊]] (請填寫於此行下方，並建議客戶合了此p***h後要驗證哪些module或feature) NoneN/A Associated Files: kernel-3.18/drivers/input/tablet/gtco.c Change-Id: I584cb0ab7b367a80b61730adea475093ca98f3f4
* ANDROID: sdcardfs: Protect set_topDaniel Rosenberg2019-07-204-28/+36
| | | | | | | | | | | | | | | If the top is changed while we're attempting to use it, it's possible that the reference will be put while we are in the process of grabbing a reference. Now we grab a spinlock to protect grabbing our reference count. Additionally, we now set the inode_info's top value to point to it's own data when initializing, which makes tracking changes easier. Change-Id: If15748c786ce4c0480ab8c5051a92523aff284d2 Signed-off-by: Daniel Rosenberg <drosen@google.com>
* Revert "ANDROID: sdcardfs: notify lower file of opens"Daniel Rosenberg2019-07-201-2/+0
| | | | | | | | | | | | This reverts commit fd825dd8ffd9c4873f80438c3030dd21c204512d. Instead of calling notify within sdcardfs, which reverse the order of notifications during an open with truncate, we'll make fs_notify worry about it. Change-Id: Ic634401c0f223500066300a4df8b1453a0b35b60 Bug: 70706497 Signed-off-by: Daniel Rosenberg <drosen@google.com>
* ANDROID: sdcardfs: Use lower getattr times/sizeDaniel Rosenberg2019-07-201-10/+9
| | | | | | | | | We now use the lower filesystem's getattr for time and size related information. Change-Id: I3dd05614a0c2837a13eeb033444fbdf070ddce2a Signed-off-by: Daniel Rosenberg <drosen@google.com> Bug: 72007585
* mm/oom_kill: squashed reverts to a stable stateCorinna Vinschen2019-07-1910-202/+215
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "mm, oom: fix use-after-free in oom_kill_process" This reverts commit e1bebdeedb497f03d426c85a89c3807c7e75268d. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm,oom: make oom_killer_disable() killable" This reverts commit 65a7400a432639aa8d5e572f30687fbca204b6f8. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm: oom_kill: don't ignore oom score on exiting tasks" This reverts commit d60dae46b27a8f381e4a7ad9dde870faa49fa5f1. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm/oom_kill.c: avoid attempting to kill init sharing same memory" This reverts commit 10773c0325259d6640b93c0694b5598ddf84939f. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "CHROMIUM: DROP: mm/oom_kill: Double-check before killing a child in our place" This reverts commit 2bdd9a2042a0e12d96c545773d9d8038c920f813. Revert "mm/oom_kill: fix the wrong task->mm == mm checks in oom_kill_process()" This reverts commit 419a313435b31821e4d045ca4b7ea1cc5fa02035. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm/oom_kill: cleanup the "kill sharing same memory" loop" This reverts commit afda78c6de38f9f66eba0955153b380d540d8276. Revert "mm/oom_kill: remove the wrong fatal_signal_pending() check in oom_kill_process()" This reverts commit acde9c2ace298b249c06ec5b0b971c333449dc09. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm, oom: remove task_lock protecting comm printing" This reverts commit 9a9ca142d250ec9de1215284857f4528c6ddb080. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm/oom_kill.c: suppress unnecessary "sharing same memory" message" This reverts commit 1aa2960f7c70d65b1481f805ac73b988faff6747. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm/oom_kill.c: reverse the order of setting TIF_MEMDIE and sending SIGKILL" This reverts commit f028aedfcfd2e2bb98921b98d3ae183387ab8fed. Revert "mm, oom: remove unnecessary variable" This reverts commit 54b0b58224146d68a11bccb5e64683ab3029373a. Revert "mm/oom_kill.c: print points as unsigned int" This reverts commit 603f975a6d4f0b56c7f6df7889ef2a704eca94a3. Signed-off-by: Corinna Vinschen <xda@vinschen.de> Revert "mm: oom_kill: simplify OOM killer locking" This reverts commit 7951a52ed35d162063fa08b27894e302fd716ccd. Revert "mm: oom_kill: remove unnecessary locking in exit_oom_victim()" This reverts commit f0739b25ac884682865d6aae7485e79489107bfb. Revert "mm: oom_kill: generalize OOM progress waitqueue" This reverts commit eb4b1243c72ba0b392bbe05dbf9f91959f70eb18. Revert "mm: oom_kill: switch test-and-clear of known TIF_MEMDIE to clear" This reverts commit e611f16275c3642cb8a6345ff2470926fef52110. Revert "mm: oom_kill: clean up victim marking and exiting interfaces" This reverts commit c6fada01b9370e3d7603b4ad8c26b56759174667. Revert "mm: oom_kill: remove unnecessary locking in oom_enable()" This reverts commit 5dd152d7351b3805f59b2b1f624722ab2f3c5fd8. Revert "oom, PM: make OOM detection in the freezer path raceless" This reverts commit 5fc5b1ddee5404a7629dd7045f54eaf8941bc11c.
* mm: Add notifier framework for showing memoryLaura Abbott2019-07-193-1/+76
| | | | | | | | | | | | There are many drivers in the kernel which can hold on to lots of memory. It can be useful to dump out all those drivers at key points in the kernel. Introduct a notifier framework for dumping this information. When the notifiers are called, drivers can dump out the state of any memory they may be using. Change-Id: Ifb2946964bf5d072552dd56d8d6dfdd794af6d84 Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
* memcg: Allow non-root users permission to control memoryChintan Pandya2019-07-191-0/+18
| | | | | | | | | | | | | | | | | In a system like Android, a process with SYS_ADMIN rights controls the system for things like moving process from one cgroup to another. The native cgroup capabilities are only allowed to execute by root user and not system. While adding a new cgroup sub-system, one may override and relax the permission so that 'system' can also control cgroup. Here, memcg is one such cgroup sub system which requires system level control for that. Allow non-root processes to add arbitrary into 'memory' cgroups if it has 'CAP_SYS_ADMIN' capability set. Change-Id: I43d4468186f142c176cb5b5f060751bb1b160344 Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
* unifdef.c: use memcpy() instead of the dodgy strncpy().Tony Finch2019-07-181-2/+2
| | | | | | | | This makes it clearer that I do not want a '\0' terminator. Submitted by: Carsten Hey <carsten@debian.org> Change-Id: I7b14346e2c32604afdbfd0e6b08baabe8a0ec54b
* DISP: Printk too muchElvin Zhang2019-07-181-1/+1
| | | | | | | | | | | | | [Detail] Replace DISPMSG() as DISPDBG() to reduce printk log MTK-Commit-Id: d9613f32bb286cea1ce1f4cd87a2af91557643fb Change-Id: I2d072885b6c83113490dc27823c822860ec201a5 Signed-off-by: Elvin Zhang <elvin.zhang@mediatek.com> CR-Id:ALPS03499038 Feature:Display Driver
* GPU DVFS: fix procfs write KEBrian-SY Yang2019-07-181-6/+16
| | | | | | | | | | | | | | | | [Detail] KE always happens when write /proc/gpufreq/gpufreq_fixed_freq by IoFuzz test [Solution] add input freq check MTK-Commit-Id: 74092efbcddc8d1584e56bb81df4722affa0b512 Change-Id: I10525c42e946088d63b8adeb29594f754710747f Signed-off-by: Brian-SY Yang <brian-sy.yang@mediatek.com> CR-Id: ALPS03519258 Feature: Others (cherry picked from commit bcbce651ad5b50bc7add53f65c0c355a3b932c33) (cherry picked from commit fa8f434d44293d39b89b3b1585ae114fa1f1d549)
* masp: fix ioctl: SEC_GET_RANDOM_ID memory check rangeChin-Ting Kuo2019-07-181-1/+5
| | | | | | | | | | | | | | | [Detail] Size of RID is 16 bytes instead of 4 bytes. Instead of using "unsigned int" as input type of _IOR(), a new struct "sec_rid" which is 16 bytes in size is declared and used in order to make memory access permission check range correct. MTK-Commit-Id: 4e1c03ca23666da29bbcd024839de5ad8a3fa143 Change-Id: I892b71fb082b5b2335d29436fee1bc61cf14fc15 Signed-off-by: Chin-Ting Kuo <chin-ting.kuo@mediatek.com> CR-Id: ALPS03523553 Feature: Vulnerability Scan
* smi: log only for wrong ioctlJacky Chen2019-07-181-1/+1
| | | | | | | | | | | [Detail] log only without aee for wrong ioctl MTK-Commit-Id: bb7c3da5b777f7841bf42f3d2b3e2b5f82bc135e Change-Id: I39b4360faeb297f9febefce9c3b3b9885e0c097b Signed-off-by: Jacky Chen <ming-fan.chen@mediatek.com> CR-Id: ALPS03592077 Feature: smi
* vibrator: delete more logShangbing Hu2019-07-181-6/+7
| | | | | | | | | | | | | | | | [Detail] delete more log [Solution] delete more log MTK-Commit-Id: 1f1494edf8bb600dfede431d102a5fbbaa04816a Change-Id: I6309eb44c76b588ff44dd7f2a937b3e4c5d5e7bb Signed-off-by: Shangbing Hu <shangbing.hu@mediatek.com> CR-Id: ALPS02571387 Feature: WiFi Calling Service (cherry picked from commit 93f355c2b37d923cd463bb71e20dc8c7e7596cca) (cherry picked from commit b0e147971dcd0d178a1ee6043dcd49dec5f434e7)
* msdc: mt6735: fix code defectEdison Liu2019-07-181-0/+2
| | | | | | | | | | | | | | | | | [Detail] A malicious userspace application can corrupt kernel memory. the offset is not limited, so it will becomes a powerful arbitrary memory read/write primitive. [Solution] set the limit of the offset from 0 to 0xFFFF MTK-Commit-Id: 91446a30b6123dd3391074062dc9833d09dbcc54 Change-Id: Icf733233133bd8ed734ec69a3567e06281d982ff Signed-off-by: Edison Liu <Edison.Liu@mediatek.com> CR-Id: ALPS03684210 Feature: Others
* Bluetooth: Fix regression with minimum encryption key size alignmentMarcel Holtmann2019-07-182-14/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 693cd8ce3f882524a5d06f7800dd8492411877b3 upstream. When trying to align the minimum encryption key size requirement for Bluetooth connections, it turns out doing this in a central location in the HCI connection handling code is not possible. Original Bluetooth version up to 2.0 used a security model where the L2CAP service would enforce authentication and encryption. Starting with Bluetooth 2.1 and Secure Simple Pairing that model has changed into that the connection initiator is responsible for providing an encrypted ACL link before any L2CAP communication can happen. Now connecting Bluetooth 2.1 or later devices with Bluetooth 2.0 and before devices are causing a regression. The encryption key size check needs to be moved out of the HCI connection handling into the L2CAP channel setup. To achieve this, the current check inside hci_conn_security() has been moved into l2cap_check_enc_key_size() helper function and then called from four decisions point inside L2CAP to cover all combinations of Secure Simple Pairing enabled devices and device using legacy pairing and legacy service security model. Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections") Change-Id: I7bccd0e917f183affd7cce670203ed92dc79a4e2 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643 Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Bluetooth: Align minimum encryption key size for LE and BR/EDR connectionsMarcel Holtmann2019-07-182-0/+11
| | | | | | | | | | | | | | commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream. The minimum encryption key size for LE connections is 56 bits and to align LE with BR/EDR, enforce 56 bits of minimum encryption key size for BR/EDR connections as well. Change-Id: Iaa1e00cab1ca82f42098c461f91fe370e501d826 Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Bluetooth: Fix L2CAP information request handling for fixed channelsJohan Hedberg2019-07-181-20/+33
| | | | | | | | | | | | | | | | | | | | | | | | Even if we have no connection-oriented channels we should perform the L2CAP Information Request procedures before notifying L2CAP channels of the connection. This is so that the L2CAP channel implementations can perform checks on what the remote side supports (e.g. does it support the fixed channel in question). So far the code has relied on the l2cap_do_start() function to initiate the Information Request, however l2cap_do_start() is used on a per-channel basis and only for connection-oriented channels. This means that if there are no connection-oriented channels on the system we would never start the Information Request procedure. This patch creates a new l2cap_request_info() helper function to initiate the Information Request procedure, and ensures that it is called whenever a BR/EDR connection has been established. The patch also updates fixed channels to be notified of connection readiness only once the Information Request procedure has completed. Change-Id: I36a482189bf4735c4dc81b2668f08aa032edfdc7 Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Convert hci_conn->link_mode into flagsJohan Hedberg2019-07-185-32/+55
| | | | | | | | | | | | | Since the link_mode member of the hci_conn struct is a bit field and we already have a flags member as well it makes sense to merge these two together. This patch moves all used link_mode bits into corresponding flags. To keep backwards compatibility with user space we still need to provide a get_link_mode() helper function for the ioctl's that expect a link_mode style value. Change-Id: Ia885bce68ab454ad47230a6a577e7ddd9319d73c Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: use l2cap_chan_ready() instead of duplicate codeGustavo Padovan2019-07-181-6/+1
| | | | | | | | | | | | In this case the replacement by l2cap_chan_ready() doesn't change the code flow, the same operations will executed plus two others that have no effect: the use of the parent socket, that a non-oriented channel doesn't have and the reset of conf_state, which is also fine since the connection is ready at this point. Change-Id: I96a54cf02cfefa546949f71d2f44ffaee1c2108c Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* tcp: refine memory limit test in tcp_fragment()Eric Dumazet2019-07-181-1/+1
| | | | | | | | | | | | | | | | | | | | commit b6653b3629e5b88202be3c9abc44713973f5c4b4 upstream. tcp_fragment() might be called for skbs in the write queue. Memory limits might have been exceeded because tcp_sendmsg() only checks limits at full skb (64KB) boundaries. Therefore, we need to make sure tcp_fragment() wont punish applications that might have setup very low SO_SNDBUF values. Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits") Change-Id: If9ae777f0ccfdde732f94350aa943274ccb1d541 Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Christoph Paasch <cpaasch@apple.com> Tested-by: Christoph Paasch <cpaasch@apple.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* BACKPORT: tcp: enforce tcp_min_snd_mss in tcp_mtu_probing()Eric Dumazet2019-07-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 967c05aee439e6e5d7d805e195b3a20ef5c433d6 upstream. If mtu probing is enabled tcp_mtu_probing() could very well end up with a too small MSS. Use the new sysctl tcp_min_snd_mss to make sure MSS search is performed in an acceptable range. CVE-2019-11479 -- tcp mss hardcoded to 48 Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jonathan Lemon <jonathan.lemon@gmail.com> Cc: Jonathan Looney <jtl@netflix.com> Acked-by: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Tyler Hicks <tyhicks@canonical.com> Cc: Bruce Curtis <brucec@netflix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [BACKPORT to 3.10: use previous sysctrl method] Signed-off-by: syphyr@gmail.com Change-Id: I02c8330a38992461b89081196b1b0ad0add0e6ad
* BACKPORT: tcp: add tcp_min_snd_mss sysctlEric Dumazet2019-07-184-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5f3e2bf008c2221478101ee72f5cb4654b9fc363 upstream. Some TCP peers announce a very small MSS option in their SYN and/or SYN/ACK messages. This forces the stack to send packets with a very high network/cpu overhead. Linux has enforced a minimal value of 48. Since this value includes the size of TCP options, and that the options can consume up to 40 bytes, this means that each segment can include only 8 bytes of payload. In some cases, it can be useful to increase the minimal value to a saner value. We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility reasons. Note that TCP_MAXSEG socket option enforces a minimal value of (TCP_MIN_MSS). David Miller increased this minimal value in commit c39508d6f118 ("tcp: Make TCP_MAXSEG minimum more correct.") from 64 to 88. We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS. CVE-2019-11479 -- tcp mss hardcoded to 48 Signed-off-by: Eric Dumazet <edumazet@google.com> Suggested-by: Jonathan Looney <jtl@netflix.com> Acked-by: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Tyler Hicks <tyhicks@canonical.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [BACKPORT to 3.10: use previous sysctrl method] Signed-off-by: syphyr@gmail.com Change-Id: Ib5e91a60fe4f4c00afc27ed92b1bd8dfe39fb7c9
* tcp: limit payload size of sacked skbsEric Dumazet2019-07-185-8/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 3b4929f65b0d8249f19a50245cd88ed1a2f78cff upstream. Jonathan Looney reported that TCP can trigger the following crash in tcp_shifted_skb() : BUG_ON(tcp_skb_pcount(skb) < pcount); This can happen if the remote peer has advertized the smallest MSS that linux TCP accepts : 48 An skb can hold 17 fragments, and each fragment can hold 32KB on x86, or 64KB on PowerPC. This means that the 16bit witdh of TCP_SKB_CB(skb)->tcp_gso_segs can overflow. Note that tcp_sendmsg() builds skbs with less than 64KB of payload, so this problem needs SACK to be enabled. SACK blocks allow TCP to coalesce multiple skbs in the retransmit queue, thus filling the 17 fragments to maximal capacity. CVE-2019-11477 -- u16 overflow of TCP_SKB_CB(skb)->tcp_gso_segs Backport notes, provided by Joao Martins <joao.m.martins@oracle.com> v4.15 or since commit 737ff314563 ("tcp: use sequence distance to detect reordering") had switched from the packet-based FACK tracking and switched to sequence-based. v4.14 and older still have the old logic and hence on tcp_skb_shift_data() needs to retain its original logic and have @fack_count in sync. In other words, we keep the increment of pcount with tcp_skb_pcount(skb) to later used that to update fack_count. To make it more explicit we track the new skb that gets incremented to pcount in @next_pcount, and we get to avoid the constant invocation of tcp_skb_pcount(skb) all together. Fixes: 832d11c5cd07 ("tcp: Try to restore large SKBs while SACK processing") Change-Id: Ia549e9b12cd033edd93f90e13c6c0e255f74c399 Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jonathan Looney <jtl@netflix.com> Acked-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Tyler Hicks <tyhicks@canonical.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tcp: tcp_fragment() should apply sane memory limitsEric Dumazet2019-07-183-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream. Jonathan Looney reported that a malicious peer can force a sender to fragment its retransmit queue into tiny skbs, inflating memory usage and/or overflow 32bit counters. TCP allows an application to queue up to sk_sndbuf bytes, so we need to give some allowance for non malicious splitting of retransmit queue. A new SNMP counter is added to monitor how many times TCP did not allow to split an skb if the allowance was exceeded. Note that this counter might increase in the case applications use SO_SNDBUF socket option to lower sk_sndbuf. CVE-2019-11478 : tcp_fragment, prevent fragmenting a packet when the socket is already using more than half the allowed space Change-Id: I594a9f68263f774fa6f0824042bc287bba6dc927 Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jonathan Looney <jtl@netflix.com> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> Reviewed-by: Tyler Hicks <tyhicks@canonical.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: zero out the unused memory region in the extent tree blockSriram Rajagopalan2019-07-181-2/+15
| | | | | | | | | | | | | | | commit 592acbf16821288ecdc4192c47e3774a4c48bb64 upstream. This commit zeroes out the unused memory region in the buffer_head corresponding to the extent metablock after writing the extent header and the corresponding extent node entries. This is done to prevent random uninitialized data from getting into the filesystem when the extent block is synced. This fixes CVE-2019-11833. Signed-off-by: Sriram Rajagopalan <sriramr@arista.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Change-Id: I5d74c1731ed4806c8ddc748c08f4d325eedb5317
* mm/mincore.c: make mincore() more conservativeJiri Kosina2019-07-181-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 134fca9063ad4851de767d1768180e5dede9a881 upstream. The semantics of what mincore() considers to be resident is not completely clear, but Linux has always (since 2.3.52, which is when mincore() was initially done) treated it as "page is available in page cache". That's potentially a problem, as that [in]directly exposes meta-information about pagecache / memory mapping state even about memory not strictly belonging to the process executing the syscall, opening possibilities for sidechannel attacks. Change the semantics of mincore() so that it only reveals pagecache information for non-anonymous mappings that belog to files that the calling process could (if it tried to) successfully open for writing; otherwise we'd be including shared non-exclusive mappings, which - is the sidechannel - is not the usecase for mincore(), as that's primarily used for data, not (shared) text [jkosina@suse.cz: v2] Link: http://lkml.kernel.org/r/20190312141708.6652-2-vbabka@suse.cz [mhocko@suse.com: restructure can_do_mincore() conditions] Link: http://lkml.kernel.org/r/nycvar.YFH.7.76.1903062342020.19912@cbobk.fhfr.pm Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Josh Snyder <joshs@netflix.com> Acked-by: Michal Hocko <mhocko@suse.com> Originally-by: Linus Torvalds <torvalds@linux-foundation.org> Originally-by: Dominique Martinet <asmadeus@codewreck.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Chinner <david@fromorbit.com> Cc: Kevin Easton <kevin@guarana.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Cyril Hrubis <chrubis@suse.cz> Cc: Tejun Heo <tj@kernel.org> Cc: Kirill A. Shutemov <kirill@shutemov.name> Cc: Daniel Gruss <daniel@gruss.cc> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Change-Id: I683073478cd809cdbc21f852b959eba070ce0141
* mm: introduce vma_is_anonymous(vma) helperOleg Nesterov2019-07-182-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b5330628546616af14ff23075fbf8d4ad91f6e25 upstream. special_mapping_fault() is absolutely broken. It seems it was always wrong, but this didn't matter until vdso/vvar started to use more than one page. And after this change vma_is_anonymous() becomes really trivial, it simply checks vm_ops == NULL. However, I do think the helper makes sense. There are a lot of ->vm_ops != NULL checks, the helper makes the caller's code more understandable (self-documented) and this is more grep-friendly. This patch (of 3): Preparation. Add the new simple helper, vma_is_anonymous(vma), and change handle_pte_fault() to use it. It will have more users. The name is not accurate, say a hpet_mmap()'ed vma is not anonymous. Perhaps it should be named vma_has_fault() instead. But it matches the logic in mmap.c/memory.c (see next changes). "True" just means that a page fault will use do_anonymous_page(). Change-Id: I024c69016c5125b6f40e990a2f63c6630f641b28 Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Hugh Dickins <hughd@google.com> Cc: Pavel Emelyanov <xemul@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [bwh: Backported to 3.16 as dependency of "mm/mincore.c: make mincore() more conservative"; adjusted context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> (cherry picked from commit e3bcb8e29b639d822175be5cb1b8e6b124edf98e)
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-13 23:11:50 +0000