November 2024 - Linux-stable-mirror

[PATCH] soc: qcom: mark pd-mapper as broken

by Johan Hovold

When using the in-kernel pd-mapper on x1e80100, client drivers often fail to communicate with the firmware during boot, which specifically breaks battery and USB-C altmode notifications. This has been observed to happen on almost every second boot (41%) but likely depends on probe order: pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request: 0x10 (-125) pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125 ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125 qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications In the same setup audio also fails to probe albeit much more rarely: PDR: avs/audio get domain list txn wait failed: -110 PDR: service lookup for avs/audio failed: -110 Chris Lew has provided an analysis and is working on a fix for the ECANCELED (125) errors, but it is not yet clear whether this will also address the audio regression. Even if this was first observed on x1e80100 there is currently no reason to believe that these issues are specific to that platform. Disable the in-kernel pd-mapper for now, and make sure to backport this to stable to prevent users and distros from migrating away from the user-space service. Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation") Cc: stable(a)vger.kernel.org # 6.11 Link: https://lore.kernel.org/lkml/Zqet8iInnDhnxkT9@hovoldconsulting.com/ Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- It's now been over two months since I reported this regression, and even if we seem to be making some progress on at least some of these issues I think we need disable the pd-mapper temporarily until the fixes are in place (e.g. to prevent distros from dropping the user-space service). Johan #regzbot introduced: 1ebcde047c54 drivers/soc/qcom/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index 74b9121240f8..35ddab9338d4 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -78,6 +78,7 @@ config QCOM_PD_MAPPER select QCOM_PDR_MSG select AUXILIARY_BUS depends on NET && QRTR && (ARCH_QCOM || COMPILE_TEST) + depends on BROKEN default QCOM_RPROC_COMMON help The Protection Domain Mapper maps registered services to the domains -- 2.45.2

8 months, 2 weeks

6
18
0 0

[PATCH v2] kbuild: switch from lz4c to lz4 for compression

by Parth Pancholi

From: Parth Pancholi <parth.pancholi(a)toradex.com> Replace lz4c with lz4 for kernel image compression. Although lz4 and lz4c are functionally similar, lz4c has been deprecated upstream since 2018. Since as early as Ubuntu 16.04 and Fedora 25, lz4 and lz4c have been packaged together, making it safe to update the requirement from lz4c to lz4. Consequently, some distributions and build systems, such as OpenEmbedded, have fully transitioned to using lz4. OpenEmbedded core adopted this change in commit fe167e082cbd ("bitbake.conf: require lz4 instead of lz4c"), causing compatibility issues when building the mainline kernel in the latest OpenEmbedded environment, as seen in the errors below. This change also updates the LZ4 compression commands to make it backward compatible by replacing stdin and stdout with the '-' option, due to some unclear reason, the stdout keyword does not work for lz4 and '-' works for both. In addition, this modifies the legacy '-c1' with '-9' which is also compatible with both. This fixes the mainline kernel build failures with the latest master OpenEmbedded builds associated with the mentioned compatibility issues. LZ4 arch/arm/boot/compressed/piggy_data /bin/sh: 1: lz4c: not found ... ... ERROR: oe_runmake failed Cc: stable(a)vger.kernel.org Link: https://github.com/lz4/lz4/pull/553 Suggested-by: Francesco Dolcini <francesco.dolcini(a)toradex.com> Signed-off-by: Parth Pancholi <parth.pancholi(a)toradex.com> --- v2: correct the compression command line to make it compatible with lz4 v1: https://lore.kernel.org/all/20241112150006.265900-1-parth105105@gmail.com/ --- Makefile | 2 +- scripts/Makefile.lib | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 79192a3024bf..7630f763f5b2 100644 --- a/Makefile +++ b/Makefile @@ -508,7 +508,7 @@ KGZIP = gzip KBZIP2 = bzip2 KLZOP = lzop LZMA = lzma -LZ4 = lz4c +LZ4 = lz4 XZ = xz ZSTD = zstd diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 01a9f567d5af..fe5e132fcea8 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -371,10 +371,10 @@ quiet_cmd_lzo_with_size = LZO $@ cmd_lzo_with_size = { cat $(real-prereqs) | $(KLZOP) -9; $(size_append); } > $@ quiet_cmd_lz4 = LZ4 $@ - cmd_lz4 = cat $(real-prereqs) | $(LZ4) -l -c1 stdin stdout > $@ + cmd_lz4 = cat $(real-prereqs) | $(LZ4) -l -9 - - > $@ quiet_cmd_lz4_with_size = LZ4 $@ - cmd_lz4_with_size = { cat $(real-prereqs) | $(LZ4) -l -c1 stdin stdout; \ + cmd_lz4_with_size = { cat $(real-prereqs) | $(LZ4) -l -9 - -; \ $(size_append); } > $@ # U-Boot mkimage -- 2.34.1

8 months, 2 weeks

6
9
0 0

[PATCH v2 7/7] ima: Reset IMA_NONACTION_RULE_FLAGS after post_setattr

by Roberto Sassu

From: Roberto Sassu <roberto.sassu(a)huawei.com> Commit 11c60f23ed13 ("integrity: Remove unused macro IMA_ACTION_RULE_FLAGS") removed the IMA_ACTION_RULE_FLAGS mask, due to it not being used after commit 0d73a55208e9 ("ima: re-introduce own integrity cache lock"). However, it seems that the latter commit mistakenly used the wrong mask when moving the code from ima_inode_post_setattr() to process_measurement(). There is no mention in the commit message about this change and it looks quite important, since changing from IMA_ACTIONS_FLAGS (later renamed to IMA_NONACTION_FLAGS) to IMA_ACTION_RULE_FLAGS was done by commit 42a4c603198f0 ("ima: fix ima_inode_post_setattr"). Restore the original change, but with new mask 0xfb000000 since the policy-specific flags changed meanwhile, and rename IMA_ACTION_RULE_FLAGS to IMA_NONACTION_RULE_FLAGS, to be consistent with IMA_NONACTION_FLAGS. Cc: stable(a)vger.kernel.org # v4.16.x Fixes: 11c60f23ed13 ("integrity: Remove unused macro IMA_ACTION_RULE_FLAGS") Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> --- security/integrity/ima/ima.h | 1 + security/integrity/ima/ima_main.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h index 22c3b87cfcac..32ffef2cc92a 100644 --- a/security/integrity/ima/ima.h +++ b/security/integrity/ima/ima.h @@ -141,6 +141,7 @@ struct ima_kexec_hdr { /* IMA iint policy rule cache flags */ #define IMA_NONACTION_FLAGS 0xff000000 +#define IMA_NONACTION_RULE_FLAGS 0xfb000000 #define IMA_DIGSIG_REQUIRED 0x01000000 #define IMA_PERMIT_DIRECTIO 0x02000000 #define IMA_NEW_FILE 0x04000000 diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 712c3a522e6c..83e467ad18d4 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -277,7 +277,7 @@ static int process_measurement(struct file *file, const struct cred *cred, /* reset appraisal flags if ima_inode_post_setattr was called */ iint->flags &= ~(IMA_APPRAISE | IMA_APPRAISED | IMA_APPRAISE_SUBMASK | IMA_APPRAISED_SUBMASK | - IMA_NONACTION_FLAGS); + IMA_NONACTION_RULE_FLAGS); /* * Re-evaulate the file if either the xattr has changed or the -- 2.47.0.118.gfd3785337b

9 months

2
1
0 0

[PATCH v2 6/7] ima: Discard files opened with O_PATH

by Roberto Sassu

From: Roberto Sassu <roberto.sassu(a)huawei.com> According to man open.2, files opened with O_PATH are not really opened. The obtained file descriptor is used to indicate a location in the filesystem tree and to perform operations that act purely at the file descriptor level. Thus, ignore open() syscalls with O_PATH, since IMA cares about file data. Cc: stable(a)vger.kernel.org # v2.6.39.x Fixes: 1abf0c718f15a ("New kind of open files - "location only".") Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> --- security/integrity/ima/ima_main.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 50b37420ea2c..712c3a522e6c 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -202,7 +202,8 @@ static void ima_file_free(struct file *file) struct inode *inode = file_inode(file); struct ima_iint_cache *iint; - if (!ima_policy_flag || !S_ISREG(inode->i_mode)) + if (!ima_policy_flag || !S_ISREG(inode->i_mode) || + (file->f_flags & O_PATH)) return; iint = ima_iint_find(inode); @@ -232,7 +233,8 @@ static int process_measurement(struct file *file, const struct cred *cred, enum hash_algo hash_algo; unsigned int allowed_algos = 0; - if (!ima_policy_flag || !S_ISREG(inode->i_mode)) + if (!ima_policy_flag || !S_ISREG(inode->i_mode) || + (file->f_flags & O_PATH)) return 0; /* Return an IMA_MEASURE, IMA_APPRAISE, IMA_AUDIT action -- 2.47.0.118.gfd3785337b

9 months

3
3
0 0

[PATCH v2] cdx: Fix possible UAF error in driver_override_show()

by Qiu-ji Chen

There is a data race between the functions driver_override_show() and driver_override_store(). In the driver_override_store() function, the assignment to ret calls driver_set_override(), which frees the old value while writing the new value to dev. If a race occurs, it may cause a use-after-free (UAF) error in driver_override_show(). To fix this issue, we adopt a logic similar to the driver_override_show() function in vmbus_drv.c, protecting dev within a lock to ensure its value remains unchanged. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: 48a6c7bced2a ("cdx: add device attributes") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> --- V2: Modified the title and description. Removed the changes to cdx_bus_match(). --- drivers/cdx/cdx.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/cdx/cdx.c b/drivers/cdx/cdx.c index 07371cb653d3..4af1901c9d52 100644 --- a/drivers/cdx/cdx.c +++ b/drivers/cdx/cdx.c @@ -470,8 +470,12 @@ static ssize_t driver_override_show(struct device *dev, struct device_attribute *attr, char *buf) { struct cdx_device *cdx_dev = to_cdx_device(dev); + ssize_t len; - return sysfs_emit(buf, "%s\n", cdx_dev->driver_override); + device_lock(dev); + len = sysfs_emit(buf, "%s\n", cdx_dev->driver_override); + device_unlock(dev); + return len; } static DEVICE_ATTR_RW(driver_override); -- 2.34.1

9 months

2
3
0 0

[PATCH v2 1/1] mtd: spi-nor: core: replace dummy buswidth from addr to data

by Cheng Ming Lin

From: Cheng Ming Lin <chengminglin(a)mxic.com.tw> The default dummy cycle for Macronix SPI NOR flash in Octal Output Read Mode(1-1-8) is 20. Currently, the dummy buswidth is set according to the address bus width. In the 1-1-8 mode, this means the dummy buswidth is 1. When converting dummy cycles to bytes, this results in 20 x 1 / 8 = 2 bytes, causing the host to read data 4 cycles too early. Since the protocol data buswidth is always greater than or equal to the address buswidth. Setting the dummy buswidth to match the data buswidth increases the likelihood that the dummy cycle-to-byte conversion will be divisible, preventing the host from reading data prematurely. Fixes: 0e30f47232ab5 ("mtd: spi-nor: add support for DTR protocol") Cc: stable(a)vger.kernel.org Reviewd-by: Pratyush Yadav <pratyush(a)kernel.org> Signed-off-by: Cheng Ming Lin <chengminglin(a)mxic.com.tw> --- drivers/mtd/spi-nor/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index f9c189ed7353..c7aceaa8a43f 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -89,7 +89,7 @@ void spi_nor_spimem_setup_op(const struct spi_nor *nor, op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto); if (op->dummy.nbytes) - op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto); + op->dummy.buswidth = spi_nor_get_protocol_data_nbits(proto); if (op->data.nbytes) op->data.buswidth = spi_nor_get_protocol_data_nbits(proto); -- 2.25.1

9 months

6
10
0 0

[PATCH v3] usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs

by Krishna Kurapati

It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list. Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy shows one byte coming in extra confirming that the byte is coming in from PC: Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722) According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize. Cc: <stable(a)vger.kernel.org> Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added") Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> --- Link to v2: https://lore.kernel.org/all/20240131150332.1326523-1-quic_kriskura@quicinc.… Changes in v2: Added check to see if the padded byte is 0x00. Changes in v3: Removed wMaxPacketSize check from v2. drivers/usb/gadget/function/f_ncm.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c index ca5d5f564998..e2a059cfda2c 100644 --- a/drivers/usb/gadget/function/f_ncm.c +++ b/drivers/usb/gadget/function/f_ncm.c @@ -1338,7 +1338,15 @@ static int ncm_unwrap_ntb(struct gether *port, "Parsed NTB with %d frames\n", dgram_counter); to_process -= block_len; - if (to_process != 0) { + + /* + * Windows NCM driver avoids USB ZLPs by adding a 1-byte + * zero pad as needed. + */ + if (to_process == 1 && + (*(unsigned char *)(ntb_ptr + block_len) == 0x00)) { + to_process--; + } else if (to_process > 0) { ntb_ptr = (unsigned char *)(ntb_ptr + block_len); goto parse_ntb; } -- 2.34.1

9 months

3
9
0 0

[PATCH v2] Bluetooth: qca: Support downloading board ID specific NVM for WCN6855

by Zijun Hu

For WCN6855, board ID specific NVM needs to be downloaded once board ID is available, but the default NVM is always downloaded currently, and the wrong NVM causes poor RF performance which effects user experience. Fix by downloading board ID specific NVM if board ID is available. Cc: Bjorn Andersson <bjorande(a)quicinc.com> Cc: Aiqun Yu (Maria) <quic_aiquny(a)quicinc.com> Cc: Cheng Jiang <quic_chejiang(a)quicinc.com> Cc: Johan Hovold <johan(a)kernel.org> Cc: Jens Glathe <jens.glathe(a)oldschoolsolutions.biz> Cc: Steev Klimaszewski <steev(a)kali.org> Cc: Paul Menzel <pmenzel(a)molgen.mpg.de> Fixes: 095327fede00 ("Bluetooth: hci_qca: Add support for QTI Bluetooth chip wcn6855") Cc: stable(a)vger.kernel.org # 6.4 Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Tested-by: Johan Hovold <johan+linaro(a)kernel.org> Tested-by: Steev Klimaszewski <steev(a)kali.org> Tested-by: Jens Glathe <jens.glathe(a)oldschoolsolutions.biz> Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- Thank you Paul, Jens, Steev, Johan, Luiz for code review, various verification, comments and suggestions. these comments and suggestions are very good, and all of them are taken by this v2 patch. Regarding the variant 'g', sorry for that i can say nothing due to confidential information (CCI), but fortunately, we don't need to care about its difference against one without 'g' from BT host perspective, qca_get_hsp_nvm_name_generic() shows how to map BT chip to firmware. I will help to backport it to LTS kernels ASAP once this commit is mainlined. --- Changes in v2: - Correct subject and commit message - Temporarily add nvm fallback logic to speed up backport. — Add fix/stable tags as suggested by Luiz and Johan - Link to v1: https://lore.kernel.org/r/20241113-x13s_wcn6855_fix-v1-1-15af0aa2549c@quici… --- drivers/bluetooth/btqca.c | 44 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 41 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index dfbbac92242a..ddfe7e3c9b50 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -717,6 +717,29 @@ static void qca_generate_hsp_nvm_name(char *fwname, size_t max_size, snprintf(fwname, max_size, "qca/hpnv%02x%s.%x", rom_ver, variant, bid); } +static void qca_get_hsp_nvm_name_generic(struct qca_fw_config *cfg, + struct qca_btsoc_version ver, + u8 rom_ver, u16 bid) +{ + const char *variant; + + /* hsp gf chip */ + if ((le32_to_cpu(ver.soc_id) & QCA_HSP_GF_SOC_MASK) == QCA_HSP_GF_SOC_ID) + variant = "g"; + else + variant = ""; + + if (bid == 0x0) + snprintf(cfg->fwname, sizeof(cfg->fwname), "qca/hpnv%02x%s.bin", + rom_ver, variant); + else if (bid & 0xff00) + snprintf(cfg->fwname, sizeof(cfg->fwname), "qca/hpnv%02x%s.b%x", + rom_ver, variant, bid); + else + snprintf(cfg->fwname, sizeof(cfg->fwname), "qca/hpnv%02x%s.b%02x", + rom_ver, variant, bid); +} + static inline void qca_get_nvm_name_generic(struct qca_fw_config *cfg, const char *stem, u8 rom_ver, u16 bid) { @@ -810,8 +833,15 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, /* Give the controller some time to get ready to receive the NVM */ msleep(10); - if (soc_type == QCA_QCA2066 || soc_type == QCA_WCN7850) + switch (soc_type) { + case QCA_QCA2066: + case QCA_WCN6855: + case QCA_WCN7850: qca_read_fw_board_id(hdev, &boardid); + break; + default: + break; + } /* Download NVM configuration */ config.type = TLV_TYPE_NVM; @@ -848,8 +878,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, "qca/msnv%02x.bin", rom_ver); break; case QCA_WCN6855: - snprintf(config.fwname, sizeof(config.fwname), - "qca/hpnv%02x.bin", rom_ver); + qca_get_hsp_nvm_name_generic(&config, ver, rom_ver, boardid); break; case QCA_WCN7850: qca_get_nvm_name_generic(&config, "hmt", rom_ver, boardid); @@ -861,9 +890,18 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, } } +download_nvm: err = qca_download_firmware(hdev, &config, soc_type, rom_ver); if (err < 0) { bt_dev_err(hdev, "QCA Failed to download NVM (%d)", err); + if (err == -ENOENT && boardid != 0 && + soc_type == QCA_WCN6855) { + boardid = 0; + qca_get_hsp_nvm_name_generic(&config, ver, + rom_ver, boardid); + bt_dev_warn(hdev, "QCA fallback to default NVM"); + goto download_nvm; + } return err; } --- base-commit: e88b020190bf5bc3e7ce5bd8003fc39b23cc95fe change-id: 20241113-x13s_wcn6855_fix-53c573ff7878 Best regards, -- Zijun Hu <quic_zijuhu(a)quicinc.com>

9 months, 1 week

5
8
0 0

[PATCH v2] samples/landlock: Fix possible NULL dereference in parse_path()

by Gax-c

From: Zichen Xie <zichenxie0106(a)gmail.com> malloc() may return NULL, leading to NULL dereference. Add a NULL check. Fixes: ba84b0bf5a16 ("samples/landlock: Add a sandbox manager example") Signed-off-by: Zichen Xie <zichenxie0106(a)gmail.com> Cc: stable(a)vger.kernel.org --- v2: Modify logic & Add Fixes tag. --- samples/landlock/sandboxer.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/samples/landlock/sandboxer.c b/samples/landlock/sandboxer.c index 57565dfd74a2..ef2a34173d84 100644 --- a/samples/landlock/sandboxer.c +++ b/samples/landlock/sandboxer.c @@ -91,6 +91,9 @@ static int parse_path(char *env_path, const char ***const path_list) } } *path_list = malloc(num_paths * sizeof(**path_list)); + if (*path_list == NULL) + return -1; + for (i = 0; i < num_paths; i++) (*path_list)[i] = strsep(&env_path, ENV_DELIMITER); @@ -127,6 +130,11 @@ static int populate_ruleset_fs(const char *const env_var, const int ruleset_fd, env_path_name = strdup(env_path_name); unsetenv(env_var); num_paths = parse_path(env_path_name, &path_list); + if (num_paths == -1) { + fprintf(stderr, "Failed to allocate memory\n"); + ret = 1; + goto out_free_name; + } if (num_paths == 1 && path_list[0][0] == '\0') { /* * Allows to not use all possible restrictions (e.g. use -- 2.34.1

9 months, 1 week

2
1
0 0

Taking a look at the NRF Retail Show 2025

by Rachel Taylor

Hi , Hope this email finds you well I am reaching out to let you know that we have a list of attendees in NRF 2025 Retail's Big Show Attendees count: 20,000 Leads Contact Information: Company Name, Web URL, Contact Name, Title, Direct Email, Phone Number, FAX Number, Mailing Address, Industry, Employee Size, Annual Sales. Please let me know if you are interested in acquiring this list, I can share pricing information for you review I would like to thank you for never keeping me waiting for your reply Regards Rachel Taylor Demand Generation Manager Apollo Leads Hub Inc., Please reply with REMOVE if you don't wish to receive further emails

9 months, 1 week

1
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024